Merge patch series "Adjust how autoprobe is implemented"

Simon Glass <[email protected]> says:

This little series makes a minor change to how autoprobe is
implemented, as discussed on the list.

Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]

1 files changed, 17 insertions, 0 deletions

diff --git a/doc/develop/driver-model/design.rst b/doc/develop/driver-model/design.rst
index 8c2c81d7ac9..92f638a0204 100644
--- a/doc/develop/driver-model/design.rst
+++ b/doc/develop/driver-model/design.rst
@@ -842,6 +842,23 @@ steps (see device_probe()):
       cause the uclass to do some housekeeping to record the device as
       activated and 'known' by the uclass.
 
+For some platforms, certain devices must be probed to get the platform into
+a working state. To help with this, drivers marked with DM_FLAG_PROBE_AFTER_BIND
+will be probed immediately after all devices are bound. For now, this happens in
+SPL, before relocation and after relocation. See the call to ``dm_autoprobe()``
+for where this is done.
+
+The auto-probe feature is tricky because it bypasses the normal ordering of
+probing. General, if device A (e.g. video) needs device B (e.g. clock), then
+A's probe() method uses ``clk_get_by_index()`` and B is probed before A. But
+A is only probed when it is used. Therefore care should be taken when using
+auto-probe, limiting it to devices which truly are essential, such as power
+domains or critical clocks.
+
+See here for more discussion of this feature:
+
+:Link: https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
+
 Running stage
 ^^^^^^^^^^^^^