On Tue, Jun 21, 2011 at 06:27:45PM +0100, Mark Brown wrote: > On Tue, Jun 21, 2011 at 06:34:48AM -0700, Dmitry Torokhov wrote: > > On Jun 21, 2011 3:46 PM, "Mark Brown" <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > > > On Mon, Jun 20, 2011 at 01:45:12AM -0700, Dmitry Torokhov wrote: > > > > 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. > > Right, but this is something that it's not reasonable to implement in > board code - if nothing else implementing it in board code would mean > we'd got lots of repitition of common patterns. I agree here. I just disagree that we should be implementing this in driver core by having special -EAGAIN handling. Having a common library-like code (probably tied to device-tree) that handles device dependencies would be great. > > > > 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. > > Absolutely, board code or data should provide the information about how > things are wired up. It's the acting on it bit that's the issue. > > > > > How about we do not register device until all resources are ready? This > > > > is pretty simple concept - do not create an object until it is usable. > > Then > > > > nobody needs to bother with -EAGAIN or -ENOTYET or any other similar > > > > garbage. > > > > As soon as you let the user build drivers modular this goes out of the > > > window. > > > Why is that? If device is registered only when it is ready to be bound to > > then it does not matter when the driver is registered and whether it is > > built into the kernel or as a module. > > Originally you were talking about registration ordering - solving the > module load issues also requires dynamic delays and rollbacks when > things get unregisterd, something that goes well beyond simple ordering > of the registrations. I always was only saying that devices should be registered when they are ready. It is my understanding that normally board code tries to register all devices; drivers may or may not be compiled as modules. Not that we could not have devices created by modules... > > > > All the faff with initcall ordering that we do at the minute is > > > essentially trying to implement this mechanism. > > > No, what you are doing is creating devices before they are usable and > > postponing the driver registration in hopes that devices will be ready by > > that time. > > Right, which is controlling the ordering of registration so that things > generally work out OK as described above. > > Nobody's arguing that we don't want to solve this in a better way, we're > just saying that actually doing that requires improvements in both core > infrastructure and the data we've got available to the infrastructure so > there's no reasonable solutions that we can deploy which are better than > the initcall ordering stuff we're doing at the minute. Ah, OK, so we basically in agreement here with the exception that I do not want the band-aid to hit mainline since it takes the heat off people who need inter-device dependency to actually work. Can the initcall stuff be kept out of mainline? I'd expect there exist board-specific trees where such patches could be kept? Or maybe interested parties could create board-crap tree to store patches like this one? Thanks. -- Dmitry -- 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
