On Tue, 21 Jun 2011 06:34:48 -0700 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Jun 21, 2011 3:46 PM, "Mark Brown" <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > wrote: > > > > On Mon, Jun 20, 2011 at 01:45:12AM -0700, Dmitry Torokhov wrote: > > > > > This is a laudable goal, but then device-tree needs to be able to > > > express device dependencies better. Until then board-specific code is > > > needed to register devices in proper order. > > > > Like Grant says this really isn't terribly sustainable - it's not just > > the device registration you need to sort out, it's also the registration > > of the drivers so things actually get bound and handing of any delays in > > the process of getting things to appear. > > If devices are registered only when they are fully usable then driver > registration does not matter. > > > It's not trivial to get this > > right in the general case and it's not reasonable to expect individual > > boards to open code things, > > Board code has the ultimate knowledge about connected devices though. Ok, let me try this essay: Board code, if there is any, or device-tree, or any other source of setup information knows best what needs to be initialized or bound when and in which order. If there is board code, one could solve this by embedding the logic in synchronous (initcall-based) or asynchronous (thread) board setup code. It is done on ARM that way, and IMHO it stinks, and AFAICS even Linus would probably agree (see http://thread.gmane.org/gmane.linux.ports.arm.kernel/113483/focus=113895 ). But we already have one example of non-code based setup information sources, which is the device-tree. A flexible system should not lock out the possibility that there are other such sources which favor generic code and dis-favor specific board setup code (reinventing wheels btw). So I guess everyone agrees that some core-infrastructure is missing to solve this problem "correctly". Since requiring board-specific code is not desirable due to the reasons stated above, what should we do in the meantime? IMHO, the late_initcall thing is both simple and should increase chances of success by a reasonable amount, while waiting for the correct solution to be implemented: An interface in the device/driver core infrastructure to specify device-dependencies in a generic and flexible way, so it can be sourced from a device-tree, board setup code (if you must) or any other source for that matter. At that moment, it is a matter of grepping for late_initcall and reverting these changes, if needed. Also, something like a keyboard driver (the part that generates input events, gpio_keys.c in this case), hardly could be a prerequisite for anything else, since it is clearly at the end of the driver food-chain. So what could possibly break by this change? 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
