On Tue, Aug 17, 2021 at 02:00:56PM -0500, Pierre-Louis Bossart wrote: > The premise of the deferred probe implementation is that a successful > driver binding is a proxy for the resources provided by this driver > becoming available. While this is a correct assumption in most of the > cases, there are exceptions to the rule such as > > a) the use of request_firmware_nowait(). In this case, the resources > may become available when the 'cont' callback completes, for example > when if the firmware needs to be downloaded and executed on a SoC > core or DSP. > > b) a split implementation of the probe with a workqueue when one or > ore request_module() calls are required: a synchronous probe prevents > other drivers from probing, impacting boot time, and an async probe is > not allowed to avoid a deadlock. This is the case on all Intel audio > platforms, with request_module() being required for the i915 display > audio and HDaudio external codecs. > > 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? > 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. 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. thanks, greg k-h
