On Wed, Aug 18, 2021 at 07:44:39AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 17, 2021 at 02:00:56PM -0500, Pierre-Louis Bossart wrote: > > In these cases, there is no way to notify the deferred probe > > infrastructure of the enablement of resources after the driver > > binding. > Then just wait for it to happen naturally? Through what mechanism will it happen naturally? Deferred probe currently only does things if things are being registered or if probes complete. > > The driver_deferred_probe_trigger() function is currently used > > 'anytime a driver is successfully bound to a device', this patch > > suggest exporing by exporting it so that drivers can kick-off > > re-probing of deferred devices at the end of a deferred processing. > I really do not want to export this as it will get really messy very > quickly with different drivers/busses attempting to call this. I'm not sure I see the mess here - it's just queueing some work, one of the things that the workqueue stuff does well is handle things getting scheduled while they're already queued. Honestly having understood their problem I think we need to be adding these calls into all the resource provider APIs. > Either handle it in your driver (why do you have to defer probe at all, > just succeed and move on to register the needed stuff after you are > initialized) or rely on the driver core here. That's exactly what they're doing currently and the driver core isn't delivering. Driver A is slow to start up and providing a resource to driver B, this gets handled in driver A by succeeding immediately and then registering the resource once the startup has completed. Unfortunately while that was happening not only has driver B registered and deferred but the rest of the probes/defers in the system have completed so the deferred probe mechanism is idle. Nothing currently tells the deferred probe mechanism that a new resource is now available so it never retries the probe of driver B. The only way I can see to fix this without modifying the driver core is to make driver A block during probe but that would at best slow down boot. The issue is that the driver core is using drivers completing probe as a proxy for resources becoming available. That works most of the time because most probes are fully synchronous but it breaks down if a resource provider registers resources outside of probe, we might still be fine if system boot is still happening and something else probes but only through luck.
Attachment:
signature.asc
Description: PGP signature
