doc: dm: clarify activation.

Explain when devices should get activated.

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc/develop/driver-model/design.rst

@@ -794,8 +794,27 @@ fall afoul of this rule.
 Activation/probe
 ^^^^^^^^^^^^^^^^
 
-When a device needs to be used, U-Boot activates it, by first reading ofdata
-as above and then following these steps (see device_probe()):
+To save resources devices in U-Boot are probed lazily. U-Boot is a bootloader,
+not an operating system. Many devices are never used during an U-Boot run, and
+probing them takes time, requires memory, may add delays to the main loop, etc.
+
+The device should be probed by the uclass code or generic device code (e.g.
+device_find_global_by_ofnode()). Uclasses differ but two common use cases can be
+seen:
+
+   1. The uclass is asked to look up a specific device, such as SPI bus 0,
+      first chip select - in this case the returned device should be
+      activated.
+
+   2. The uclass is asked to perform a specific function on any device that
+      supports it, eg. reset the board using any sysreset that can be found -
+      for this case the core uclass code provides iterators that activate
+      each device before returning it, and the uclass typically implements a
+      walk function that iterates over all devices of the uclass and tries
+      to perform the requested function on each in turn until succesful.
+
+To activate a device U-Boot first reads ofdata as above and then follows these
+steps (see device_probe()):
 
    1. All parent devices are probed. It is not possible to activate a device
       unless its predecessors (all the way up to the root device) are activated.