linux-kernel - Re: [RFC PATCH v2 07/16] gpio: Add support for unified device properties interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 08 Oct 2014 01:57:11 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Darren Hart <dvhart@...radead.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Len Brown <Len.Brown@...el.com>, Arnd Bergmann <arnd@...db.de>,
	David Woodhouse <david.woodhouse@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Bryan Wu <cooloney@...il.com>,
	Lee Jones <lee.jones@...aro.org>, Aaron Lu <aaron.lu@...el.com>
Subject: Re: [RFC PATCH v2 07/16] gpio: Add support for unified device properties interface

On Tuesday, October 07, 2014 03:37:04 PM Linus Walleij wrote:
> On Fri, Sep 26, 2014 at 5:21 AM, Darren Hart <dvhart@...radead.org> wrote:
> > On Wed, Sep 24, 2014 at 11:12:36AM +0200, Arnd Bergmann wrote:
> 
> > So as Mika has pointed out, LEDs aren't the only ones affected. Several drivers
> > will need to walk through non-device child nodes, and it seems to me that having
> > a firmware-independent mechanism to do so benefits the drivers by both making
> > them smaller and by increasing the reusability of new drivers and drivers
> > updated to use the new API across platforms.
> 
> In a recent round of reviews, for the OF case, that led to drivers
> which used device_initcall() without being a module, getting a match
> and handle to the parent device, and then walking over the nodes
> and instantiating child objects (Linux devices usually) in the process.
> 
> It was done as a response to the remark from Rob Herring that
> we were modeling things in the device tree as devices when they
> really weren't, we were just doing it that way because it fits the
> Linux device model and it's easier.
> 
> So we have that case too.
> 
> The question is if it's anything close to generalizable.

Well, OK.

Can you please have a look at these patchse in v4:

https://patchwork.kernel.org/patch/5040161/
https://patchwork.kernel.org/patch/5040081/
https://patchwork.kernel.org/patch/5040061/

We now have an ACK from Dmitry on the gpio_keys_polled thing and Bryan
said he was OK with the leds changes already in v2 (IIRC).

Also Alexandre is saying that he's not opposed to the changes in
https://patchwork.kernel.org/patch/5040161/, although there may be a better
way.

And we have AKCs from Greg on the driver core changes, so it looks like
GPIO really is the only missing thing and we need that code to support
our hardware.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/