On Sat, Jun 18, 2011 at 4:17 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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. -- 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
