On 4/10/24 15:44, Tom Rini wrote:
On Wed, Apr 10, 2024 at 07:27:17PM +0200, Heinrich Schuchardt wrote:
Am 10. April 2024 19:06:57 MESZ schrieb Caleb Connolly
<caleb.conno...@linaro.org>:
Introduce support for a uclass to provide a fallback/stub driver which
can be used when no device is found for a given node. This might be
useful for handling non-essential clock controllers like the RPMh on
Qualcomm platforms, or during early bringup to get UART output before a
real clock driver has been created.
Signed-off-by: Caleb Connolly <caleb.conno...@linaro.org>
---
drivers/core/Kconfig | 10 ++++++++++
drivers/core/uclass.c | 24 +++++++++++++++++++++++-
include/dm/uclass.h | 3 +++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 1081d61fcf01..09075b9b7a15 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -466,5 +466,15 @@ config BOUNCE_BUFFER
A second possible use of bounce buffers is their ability to
provide aligned buffers for DMA operations.
+menuconfig FALLBACK_DRIVERS
Wouldn't it be preferable to mark individual drivers as fallback drivers in
their declaration?
This would allow alternative fallback drivers and would not require any
definitions at uclass level.
Just by building a fallback driver you would enable the fallback behavior for
its uclass.
I think some of this is addressed in the cover letter. My concern /
questions come down to I think just a matter of naming. Both "fallback"
and "stub" are used at times. As a concept, we have some areas where we
need a no-op driver because whereas the DT describes a relationship in
the hardware, here in U-Boot we can just accept things as configured. To
me "fallback" implies more functionality of the driver when it's really
just a generic no-op driver to fill in the dependencies within the tree.
Can we rename things a bit along those lines?
I would rather just have a stub driver with compatibles for all clocks we want
it to match. I think having a generic fallback driver could cause issues in the
future if we need to switch over to using a real driver.
--Sean
