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? -- Tom
signature.asc
Description: PGP signature
