On Wed, Aug 18, 2021 at 12:57:36PM +0100, Mark Brown wrote: > 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. The driver core is not using that as a proxy, that is up to the driver itself or not. All probe means is "yes, this driver binds to this device, thank you!" for that specific bus/class type. That's all, if the driver needs to go off and do real work before it can properly control the device, wonderful, have it go and do that async. So if you know you should be binding to the device, great, kick off some other work and return success from probe. There's no reason you have to delay or defer for no good reason, right? But yes, if you do get new resources, the probe should be called again, that's what the deferred logic is for (or is that the link logic, I can't recall) This shouldn't be a new thing, no needing to call the driver core directly like this at all, it should "just happen", right? thanks, greg k-h
