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.