[PATCH 1/2] dm: core: add support for fallback drivers

[Sean Anderson]

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.connolly at 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.connolly at 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