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  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 <>
To:	Linus Walleij <>
Cc:	Darren Hart <>,
	Len Brown <>, Arnd Bergmann <>,
	"Rafael J. Wysocki" <>,
	David Woodhouse <>,
	Mika Westerberg <>,
	Grant Likely <>,
	Mark Rutland <>,
	ACPI Devel Maling List <>,
	"" <>,
	"" <>,
	Greg Kroah-Hartman <>,
	Alexandre Courbot <>,
	Dmitry Torokhov <>,
	Bryan Wu <>,
	Lee Jones <>, Aaron Lu <>
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 <> 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 <>
Intel Finland Oy

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists