As U-Boot works to align itself with upstream devicetrees, there are some common issues we start to run into, that of hardware blocks which might be important for an OS like Linux, but which aren't useful in U-Boot.
To offer an example: Qualcomm platforms feature a Resource Power Manager (RPM(h)) co-processor, it can opportunistically ramp down rails and clocks based on usage. This necessitates placing votes on these resources for every peripheral that uses them, and as a result means that many peripherals that we want to use in U-Boot contain references to the RPMh clock controller. However, we don't actually need to do this in the context of U-Boot, this is mostly something an OS would care about.
With CONFIG_OF_LIVE it would be possible to dynamically remove such references (we could for example add a "bootph-os" property to indicate that the device should be ignored by U-Boot). However OF_LIVE is not available on all boards, and is only available post-relocation. This approach would also require adding a new DT property for every arch/platform/board that we want to ignore.
We could instead try to handle this at the driver level, but this becomes intractable when trying to scale across all of the drivers and for all of the supported hardware generations. It also complicates thing if we actually want/need to use this previously optional resource in the future.
== The stub approach ==
The approach taken with this series is instead to allow for a stub driver to be defined per-uclass, with the clock subsystem being the first user. This stub driver is used as a fall back in the case where a driver requests a device of a specific type (such as a clock controller) and where no other driver binds to the node.
This solution allows us to immediately solve this issue for Qualcomm platforms, and for any other architectures with similar issues. An obvious next step is to do the same for optional power-domain controllers.
Another benefit to this approach is that it is easy to introspect, the stub drivers will show up in "dm tree". So the case of forgetting to enable a driver will be much more obvious than if we tried to find the clock, failed, and just did nothing.
== Future expansion ==
The exact scope of the stub driver (when it should match, how it should behave) obviously depends heavily on the uclass, as such I think it should be up to the subsystem maintainers.
An obvious next choice would be the power domain uclass. The current architecture of U-Boot requires either disabling CONFIG_POWER_DOMAIN, supporting every single power domain controller on your platform, or adding DM_FLAG_DEFAULT_PD_CTRL_OFF to a bunch of drivers.
--- Caleb Connolly (2): dm: core: add support for fallback drivers clk: introduce a fallback stub driver
drivers/clk/Makefile | 1 + drivers/clk/clk-fallback.c | 39 +++++++++++++++++++++++++++++++++++++++ drivers/clk/clk-uclass.c | 4 ++++ drivers/core/Kconfig | 20 ++++++++++++++++++++ drivers/core/uclass.c | 24 +++++++++++++++++++++++- include/dm/uclass.h | 3 +++ 6 files changed, 90 insertions(+), 1 deletion(-) --- change-id: 20240410-b4-stub-drivers-1c1565bb06a6 base-commit: 56c4a3aa2ed15b64eabd067a10be2091d28a5f2f
// Caleb (they/them)