Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
TODO: driver core: Break infinite loop when deferred probe can't be s…
…atisfied TODO: old scenario Consider the following scenario. The main driver of USB OTG controller (dwc3-pci), which has the following functional dependencies on certain platform: - ULPI (tusb1210) - extcon (tested with extcon-intel-mrfld) Note, that first driver, tusb1210, is available at the moment of dwc3-pci probing, while extcon-intel-mrfld is built as a module and won't appear till user space does something about it. This is depicted by kernel configuration excerpt: CONFIG_PHY_TUSB1210=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_ULPI=y CONFIG_USB_DWC3_DUAL_ROLE=y CONFIG_USB_DWC3_PCI=y CONFIG_EXTCON_INTEL_MRFLD=m In the Buildroot environment the modules are probed by alphabetical ordering of their modaliases. The latter comes to the case when USB OTG driver will be probed first followed by extcon one. So, if the platform anticipates extcon device to be appeared, in the above case we will get deferred probe of USB OTG, because of ordering. Since current implementation, done by the commit 58b116b ("drivercore: deferral race condition fix") counts the amount of triggered deferred probe, we never advance the situation -- the change makes it to be an infinite loop. ---8<---8<--- [ 22.187127] driver_deferred_probe_trigger <<< 1 ...here is the late initcall triggers deferred probe... [ 22.191725] platform dwc3.0.auto: deferred_probe_work_func in deferred list ...dwc3.0.auto is the only device in the deferred list... [ 22.198727] platform dwc3.0.auto: deferred_probe_work_func 1 <<< counter 1 ...the counter before mutex is unlocked is kept the same... [ 22.205663] platform dwc3.0.auto: Retrying from deferred list ...mutes has been unlocked, we try to re-probe the driver... [ 22.211487] bus: 'platform': driver_probe_device: matched device dwc3.0.auto with driver dwc3 [ 22.220060] bus: 'platform': really_probe: probing driver dwc3 with device dwc3.0.auto [ 22.238735] bus: 'ulpi': driver_probe_device: matched device dwc3.0.auto.ulpi with driver tusb1210 [ 22.247743] bus: 'ulpi': really_probe: probing driver tusb1210 with device dwc3.0.auto.ulpi [ 22.256292] driver: 'tusb1210': driver_bound: bound to device 'dwc3.0.auto.ulpi' [ 22.263723] driver_deferred_probe_trigger <<< 2 ...the dwc3.0.auto probes ULPI, we got successful bound and bumped counter... [ 22.268304] bus: 'ulpi': really_probe: bound device dwc3.0.auto.ulpi to driver tusb1210 [ 22.276697] platform dwc3.0.auto: Driver dwc3 requests probe deferral ...but extcon driver is still missing... [ 22.283174] platform dwc3.0.auto: Added to deferred list [ 22.288513] platform dwc3.0.auto: driver_deferred_probe_add_trigger local counter: 1 new counter 2 ...and since we had a successful probe, we got counter mismatch... [ 22.297490] driver_deferred_probe_trigger <<< 3 [ 22.302074] platform dwc3.0.auto: deferred_probe_work_func 2 <<< counter 3 ...at the end we have a new counter and loop repeats again, see 22.198727... ---8<---8<--- Revert of the commit helps, but it is probably not helpful for the initially found regression. Artem Bityutskiy suggested to use counter of the successful probes instead. This fixes above mentioned case and shouldn't prevent driver to reprobe deferred ones. Under "successful probe" we understand the state when a driver of the certain device is being kept bound after deferred probe trigger cycle. For instance, in the above mentioned case probing of tusb1210 is not successful because dwc3 driver unbinds device dwc3.0.auto.ulpi. The atomic_dec() call is used to keep track of this. The amount of bindings is always great than or equal to the amount of unbindings as guaranteed by design of the driver binding mechanism. Fixes: 58b116b ("drivercore: deferral race condition fix") Suggested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: Grant Likely <grant.likely@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Brown <broonie@kernel.org> Cc: Felipe Balbi <balbi@kernel.org> Cc: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Ferry Toth <fntoth@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
- Loading branch information