Messages in this thread | | | Date | Mon, 4 Jul 2011 10:56:49 -0700 | From | Mark Brown <> | Subject | Re: [PATCH] drivercore: Add driver probe deferral mechanism |
| |
On Mon, Jul 04, 2011 at 10:41:26AM -0700, Greg KH wrote:
> And why would a driver not be able to get all of the proper resources?
If the resources are provided by another driver (for example, a clock, GPIO or regulator) then the driver doing the providing needs to have initialized before the resource can be used. Currently we have no way of ensuring that this happens.
> Why can't a bus, at a later time, just try to reprobe everything when it > determines that it is a "later" time now, without having to do this > added change to the core?
The buses can't do anything to help as they have no visibility of this and the chances are that devices on several different buses are involved.
> Why would drivers in modules be an issue? If a driver depends on > another driver, making it a module dependancy would solve the problem, > right?
The general problem here is that the drivers depend on each other in system-specific fashions that have nothing to do with the control heirachy the device model uses - for example, a device may depend on having a clock provided but the specific clock used could come from essentially any device in a given system with the driver accessing that clock via the clock API which matches devices up with their providers. The API indirection means we can share code between systems but means that the kernel infrastructure has no visibility of the relationships.
| |