On Mon, 20 Jun 2011 12:20:30 -0600 Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > 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. Especially, how would I specify this setup handler in a device-tree? The DT compiler still has no support for something like embedded DT-script ;-) Still, an interesting (albeit smelly) idea I hadn't thought of before. Best regards, -- David Jander Protonic Holland. -- 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
