Re: [PATCH v4 3/3] Input: gpio_keys.c: Enable use with non-local GPIO chips.

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, Jun 22, 2011 at 12:02:42AM +0100, Mark Brown wrote:
> On Tue, Jun 21, 2011 at 01:48:05PM -0700, Dmitry Torokhov wrote:
> > On Tue, Jun 21, 2011 at 06:27:45PM +0100, Mark Brown wrote:
> 
> > > Right, but this is something that it's not reasonable to implement in
> > > board code - if nothing else implementing it in board code would mean
> > > we'd got lots of repitition of common patterns.
> 
> > I agree here. I just disagree that we should be implementing this in
> > driver core by having special -EAGAIN handling. Having a common
> > library-like code (probably tied to device-tree) that handles device
> > dependencies would be great.
> 
> Ah, that's more OK then.  I'm not entirely sure about the -EAGAIN
> proposal but it does seem to have some advantages in terms of
> deployment.
> 
> > Ah, OK, so we basically in agreement here with the exception that I do
> > not want the band-aid to hit mainline since it takes the heat off people
> > who need inter-device dependency to actually work.
> 
> > Can the initcall stuff be kept out of mainline? I'd expect
> 
> The init order stuff is in mainline already, you're far too late to the
> party here.

For some drivers it might be already in mainline, it does not matter
that we should continue adding more.

> 
> > there exist board-specific trees where such patches could be kept? Or
> > maybe interested parties could create board-crap tree to store patches
> > like this one?
> 
> Keeping things in board trees is exactly the sort of thing we want to
> avoid people doing.  That just means people do all sorts of stuff that
> wouldn't be acceptable upstream, either out of ignorance or through
> knowing that only their systems have to work with what they're doing,
> and just don't bother working upstream at all half the time making life
> miserable for pretty much everyone.

So you are saying that we should accept such crap directly into
mainline?

Again, it looks like we agree that shuffling initcalls is not proper
solution for this problem nor it is maintainable, so it is exactly the
kind of patches that should be kept in the board trees and out of
mainline.

-- 
Dmitry