On Mon, Jun 20, 2011 at 11:03 AM, H Hartley Sweeten <hartleys@xxxxxxxxxxxxxxxxxxx> wrote: > 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 Blech! That approach fell out of the ugly tree and hit every branch on the way down! Points for creativity though. :-) Essentially that ends up being a driver-specific notifier implementation. Yes, that works, but to me it just highlights a deficiency in the Linux device model. g. -- 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
