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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday, June 18, 2011 6:18 AM, Grant Likely wrote:
> On Sat, Jun 18, 2011 at 4:17 AM, Dmitry Torokhov 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.

To avoid the registration order issue, isn't the proper fix to use a "setup"
method in the gpio expander driver?  The gpio-pca953x.c driver has this and
I use it to hook the gpio_keys driver to those gpios.  The registration order
ends up being:

i2c-gpio as a platform_device in the machine init code
pca9539 as part of the i2c_board_info for the i2c-gpio device
gpio-keys as a platform_device via the .setup callback of pca9539

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


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux