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

[Grant Likely <grant.likely@secretlab.ca>]

On Mon, Jun 20, 2011 at 2:45 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Jun 20, 2011 at 09:48:15AM +0200, David Jander wrote:
>> On Sat, 18 Jun 2011 09:16:45 -0600
>> Grant Likely <grant.likely@secretlab.ca> wrote:
>>
>> > On Sat, Jun 18, 2011 at 07:51:54AM -0700, Dmitry Torokhov wrote:
>> > > On Sat, Jun 18, 2011 at 07:18:28AM -0600, Grant Likely wrote:
>> > > > On Sat, Jun 18, 2011 at 4:17 AM, Dmitry Torokhov
>> > > > <dmitry.torokhov@gmail.com> wrote:
>> > > > > On Thu, Jun 16, 2011 at 01:27:32PM -0600, Grant Likely wrote:
>> > > > >> On Tue, Jun 14, 2011 at 11:08:11AM +0200, David Jander wrote:
>> > > > >> > Use a threaded interrupt handler in order to permit the handler to
>> > > > >> > use a GPIO driver that causes things like I2C transactions being
>> > > > >> > done inside the handler context.
>> > > > >> > Also, gpio_keys_init needs to be declared as a late_initcall, to
>> > > > >> > make sure all needed GPIO drivers have been loaded if the drivers
>> > > > >> > are built into the kernel.
>> > > > >>
>> > > > >> ...which is a horrid hack, but until device dependencies can be
>> > > > >> described, it isn't one that can be solved easily.
>> > > > >>
>> > > > >
>> > > > > I really do not want to apply this... Currently the order of
>> > > > > initialization does not matter since nothing actually happens until
>> > > > > corresponding device appears on the bus. Does the OF code creates
>> > > > > devices before all resources are ready?
>> > > >
>> > > > It's not an OF problem.  The problem is that all the platform_devices
>> > > > typically get registered all at once at machine_init time (on arm),
>> > > > and if the gpio expander isn't a platform_device, (like an i2c gpio
>> > > > expander which would end up being a child of a platform_device), then
>> > > > it won't be ready.
>> > >
>> > > Ah, I see. But that can be handled in board code that should ensure that
>> > > it registers devices in correct order.
>> >
>> > Unfortunately, handling it in board code doesn't really work either.
>> > It just shuffles the complexity to the board code to implement some
>> > kind of deferred mechanism for registering devices, and it has to take
>> > into account that it may be a long time before the device actually
>> > appears, such as when the driver is configured as a module.
>>
>> Besides... we don't want anymore board-code, do we? I mean, if a board can use
>> a generic board configuration and specify all it needs in the device-tree, why
>> should something as trivial as connecting a gpio_keys device to a I2C GPIO
>> expander force us to do special board setup all of a sudden?
>> IMHO specifying I2C-gpios to be used for gpio_keys should "just work", even if
>> declared in a device-tree.
>
> This is a laudable goal, but then device-tree needs to be able to
> express device dependencies better. Until then board-specific code is
> needed to register devices in proper order.

Do:
$ git grep _initcall drivers/gpio
and
$ git grep module_init drivers/gpio

I curse and hold my nose every time I have to apply one of those
initcall patches, but I have to anyway since there isn't even a good
way in board-specific code to control the device registration order.
Everything gets registered at machine_init time, and the /order/ that
things get registered has barely any effect.  It all ends up hanging
on the initcall order.  The only way for board code to have a
meaningful impact on initialization order is to wait for a driver to
get probed on a prerequisite device, probably by using a notifier, and
then register the device at that point.

As far as I can tell, no board code does that.  As ugly as fiddling
with initcall levels is, it has been sufficient up to this point for
existing (non-DT) board ports.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html