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

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

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.  The real problem is that we have no mechanism for
holding off or deferring a driver probe if it depends on an
asynchronous resource.

g.