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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Oct 2014 18:37:46 +0300
From:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Darren Hart <dvhart@...radead.org>,
	Len Brown <Len.Brown@...el.com>, Arnd Bergmann <arnd@...db.de>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	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 Tue, 2014-10-07 at 15:37 +0200, 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.
> 
> > Grant, Linus W? Thoughts?
> 
> I'm uncertain on the whole subject, I called on the others
> because of that...
> 
> For a while I had Andy Schevenko patch the GPIO and
> SFI core too, but it timed out due to no response from Len
> Brown. (Maybe I should just merge that stuff!) Do you (Intel) also
> want to unify the Medfield SFI thing into this or have you
> given up on it?

I think SFI is quite outdated stuff, though I have still Medfield device
close to me.

I don't think there will be any new platform with SFI (on the other hand
we never know :-) ). Thus, my opinion you may go ahead without worrying
about SFI.

-- 
Andy Shevchenko <andriy.shevchenko@...el.com>
Intel Finland Oy

--
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/