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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, 2014-10-07 at 15:37 +0200, Linus Walleij wrote:
> On Fri, Sep 26, 2014 at 5:21 AM, Darren Hart <dvhart@infradead.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@intel.com>
Intel Finland Oy