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

On Wed, Jun 22, 2011 at 12:00:52AM -0700, Dmitry Torokhov wrote:

On Wed, Jun 22, 2011 at 12:02:42AM +0100, Mark Brown wrote:

quoted

On Tue, Jun 21, 2011 at 01:48:05PM -0700, Dmitry Torokhov wrote:

quoted

quoted

Can the initcall stuff be kept out of mainline? I'd expect

quoted

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.

It's not just a few drivers, there's entire subsystems that are doing
this.

quoted

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?

Pretty much, yes.  In code terms it's not really invasive and it doesn't
have any real impact on other systems so it's the sort of thing we can
carry without too much pain.  Pragmatically it's not unreasonable.

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.

On the other hand if we're telling people that they can't run their
system usefully from mainline (in some cases we can't even boot) then
we're sending a bad message about the usefulness of mainline and we're
encouraging a space where non-mainline code is acceptable.

The situation here is similar to what we used to have with interrupt
controllers on slow buses - we spent a while working with open coded
non-genirq implementations confined to particular drivers before genirq
was able to support this sort of hardware because there wasn't a clear
route to getting that done in a reasonable timeframe.