diff mbox series

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

Message ID 20240410-b4-stub-drivers-v1-1-6935bd2c07d1@linaro.org
State New
Headers show
Series dm: add support for stubbing optional devices | expand

Commit Message

Caleb Connolly April 10, 2024, 5:06 p.m. UTC
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@linaro.org>
---
 drivers/core/Kconfig  | 10 ++++++++++
 drivers/core/uclass.c | 24 +++++++++++++++++++++++-
 include/dm/uclass.h   |  3 +++
 3 files changed, 36 insertions(+), 1 deletion(-)

Comments

Heinrich Schuchardt April 10, 2024, 5:27 p.m. UTC | #1
Am 10. April 2024 19:06:57 MESZ schrieb Caleb Connolly <caleb.connolly@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@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.

Best regards

Heinrich

>+	bool "Enable per-uclass fallback drivers"
>+	depends on DM
>+	help
>+	  If a driver requests a resource (like a clock) from a node which
>+	  isn't bound to a driver, the driver model will look for a fallback
>+	  driver to "stub" the resource. These stubs usually do nothing and
>+	  are therefore only suitable in instances where the resource is not
>+	  required.
>+
> endmenu
>diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>index e46d5717aa62..91d3a48d77b8 100644
>--- a/drivers/core/uclass.c
>+++ b/drivers/core/uclass.c
>@@ -378,8 +378,26 @@ int uclass_find_device_by_of_offset(enum uclass_id id, int node,
> 
> 	return -ENODEV;
> }
> 
>+static int uclass_bind_fallback(struct uclass *uc, ofnode node, struct udevice **devp)
>+{
>+	struct driver *drv;
>+
>+	log(LOGC_DM, LOGL_ERR, "   - binding fallback '%s' driver '%s'\n",
>+	    uc->uc_drv->name, uc->uc_drv->fallback_drv_name);
>+
>+	drv = lists_driver_lookup_name(uc->uc_drv->fallback_drv_name);
>+	if (!drv) {
>+		log(LOGC_DM, LOGL_DEBUG, "   - Can't find stub driver '%s' for uclass '%s'\n",
>+		    uc->uc_drv->fallback_drv_name, uc->uc_drv->name);
>+		return -ENOENT;
>+	}
>+
>+	return device_bind_with_driver_data(gd->dm_root, drv,
>+					  ofnode_get_name(node), 0, node, devp);
>+}
>+
> int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
> 				 struct udevice **devp)
> {
> 	struct uclass *uc;
>@@ -401,9 +419,13 @@ int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
> 			*devp = dev;
> 			goto done;
> 		}
> 	}
>-	ret = -ENODEV;
>+
>+	if (CONFIG_IS_ENABLED(FALLBACK_DRIVERS) && uc->uc_drv->fallback_drv_name)
>+		ret = uclass_bind_fallback(uc, node, devp);
>+	else
>+		ret = -ENODEV;
> 
> done:
> 	log(LOGC_DM, LOGL_DEBUG, "   - result for %s: %s (ret=%d)\n",
> 	    ofnode_get_name(node), *devp ? (*devp)->name : "(none)", ret);
>diff --git a/include/dm/uclass.h b/include/dm/uclass.h
>index 456eef7f2f31..b99e36485bc5 100644
>--- a/include/dm/uclass.h
>+++ b/include/dm/uclass.h
>@@ -67,8 +67,10 @@ struct udevice;
>  * @child_pre_probe: Called before a child in this uclass is probed
>  * @child_post_probe: Called after a child in this uclass is probed
>  * @init: Called to set up the uclass
>  * @destroy: Called to destroy the uclass
>+ * @stub_drv_name: Name of a stub driver to use for devices that are not
>+ * supported by any other driver.
>  * @priv_auto: If non-zero this is the size of the private data
>  * to be allocated in the uclass's ->priv pointer. If zero, then the uclass
>  * driver is responsible for allocating any data required.
>  * @per_device_auto: Each device can hold private data owned
>@@ -98,8 +100,9 @@ struct uclass_driver {
> 	int (*child_pre_probe)(struct udevice *dev);
> 	int (*child_post_probe)(struct udevice *dev);
> 	int (*init)(struct uclass *class);
> 	int (*destroy)(struct uclass *class);
>+	const char *fallback_drv_name;
> 	int priv_auto;
> 	int per_device_auto;
> 	int per_device_plat_auto;
> 	int per_child_auto;
>
Tom Rini April 10, 2024, 7:44 p.m. UTC | #2
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@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@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?
Sean Anderson April 11, 2024, 2:37 a.m. UTC | #3
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@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@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
Caleb Connolly May 3, 2024, 3:53 p.m. UTC | #4
Hi all,

Sorry for the slow follow-up.

On 11/04/2024 04:37, Sean Anderson wrote:
> 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@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@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?

Yes, will do. I originally used "stub" but then decided "fallback" was 
better, but I think you're right that stub is the right way to go here. 
As I agree that "fallback" implies some kind of real implementation.
>>
> 
> 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.

I don't think either approach is significantly better from a developer 
perspective. With my patches if there a driver with a matching 
compatible available then you will NEVER bind the stub, even if probe 
fails on the real driver. With your proposal we'd have to remember to 
remove the compatible from the stub driver or risk the race condition 
when binding drivers.

There is another subtle but important difference if we were to use a 
compatible list in the stub. It turns out that CONFIG_OF_LIVE affects 
the bind behaviour - U-Boot won't try to bind the children of a node 
with no driver when using the livetree. This is arguably more "correct", 
as usually child devices depend on their parent, so we save some cycles 
by not binding unsupported devices.

But, the RPM clock controller which I originally implemented this 
feature for is such a case, this is the DT (simplified for brevity):

rpm: remoteproc {
     compatible = "qcom,sm6115-rpm-proc", "qcom,rpm-proc";

     glink-edge {
         compatible = "qcom,glink-rpm";

         rpm_requests: rpm-requests {
             compatible = "qcom,rpm-sm6115";

             rpmcc: clock-controller {
                 compatible = "qcom,rpmcc-sm6115", "qcom,rpmcc";
             };
     };
};

With livetree (which we use on qcom) we would need to stub not just the 
rpmcc but also the rpm-requests, the glink bus, and the remoteproc (yeah 
these platforms are a bit silly, I know XD).

However with the fallback solution as implemented in these patches, we 
totally sidestep this issue by directly binding the node on-demand, 
something we can only safely do for a stub driver as we don't need the 
parent devices.

So I can either:

1) Make OF_LIVE behave like flattree and descend into all nodes (I don't 
know if this would cause any issues, but I think the livetree behaviour 
is more "correct" tbh).
2) Add stubs for all 3 of the parent nodes (and manually maintain a 
table of compatibles for clock drivers we want to stub).
3) Stick with this approach of binding the stub as a last resort.

Obviously I've already put the time into 3, and that would still be my 
preferred approach, but I'm open to other ideas.

> 
> --Sean
Caleb Connolly May 3, 2024, 4:10 p.m. UTC | #5
On 10/04/2024 19:27, Heinrich Schuchardt wrote:
> 
> 
> Am 10. April 2024 19:06:57 MESZ schrieb Caleb Connolly <caleb.connolly@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@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.

I don't see an obvious usecase for having multiple stub drivers for a 
given uclass. Maybe as a result of that, I have no idea how we'd go 
about choosing which stub to use if multiple were available.

I don't think it would be particularly hard to switch over if at some 
point in the future we have such a need, but I don't see a benefit to 
this added complexity now.
> 
> Just by building a fallback driver you would enable the fallback behavior for its uclass.

I could drop the CONFIG_FALLBACK_DRIVERS option, it's just there to make 
it possible to opt in/out of all stub drivers at once, but maybe this 
isn't very useful.

Kind Regards,
> 
> Best regards
> 
> Heinrich
> 
>> +	bool "Enable per-uclass fallback drivers"
>> +	depends on DM
>> +	help
>> +	  If a driver requests a resource (like a clock) from a node which
>> +	  isn't bound to a driver, the driver model will look for a fallback
>> +	  driver to "stub" the resource. These stubs usually do nothing and
>> +	  are therefore only suitable in instances where the resource is not
>> +	  required.
>> +
>> endmenu
>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>> index e46d5717aa62..91d3a48d77b8 100644
>> --- a/drivers/core/uclass.c
>> +++ b/drivers/core/uclass.c
>> @@ -378,8 +378,26 @@ int uclass_find_device_by_of_offset(enum uclass_id id, int node,
>>
>> 	return -ENODEV;
>> }
>>
>> +static int uclass_bind_fallback(struct uclass *uc, ofnode node, struct udevice **devp)
>> +{
>> +	struct driver *drv;
>> +
>> +	log(LOGC_DM, LOGL_ERR, "   - binding fallback '%s' driver '%s'\n",
>> +	    uc->uc_drv->name, uc->uc_drv->fallback_drv_name);
>> +
>> +	drv = lists_driver_lookup_name(uc->uc_drv->fallback_drv_name);
>> +	if (!drv) {
>> +		log(LOGC_DM, LOGL_DEBUG, "   - Can't find stub driver '%s' for uclass '%s'\n",
>> +		    uc->uc_drv->fallback_drv_name, uc->uc_drv->name);
>> +		return -ENOENT;
>> +	}
>> +
>> +	return device_bind_with_driver_data(gd->dm_root, drv,
>> +					  ofnode_get_name(node), 0, node, devp);
>> +}
>> +
>> int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
>> 				 struct udevice **devp)
>> {
>> 	struct uclass *uc;
>> @@ -401,9 +419,13 @@ int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
>> 			*devp = dev;
>> 			goto done;
>> 		}
>> 	}
>> -	ret = -ENODEV;
>> +
>> +	if (CONFIG_IS_ENABLED(FALLBACK_DRIVERS) && uc->uc_drv->fallback_drv_name)
>> +		ret = uclass_bind_fallback(uc, node, devp);
>> +	else
>> +		ret = -ENODEV;
>>
>> done:
>> 	log(LOGC_DM, LOGL_DEBUG, "   - result for %s: %s (ret=%d)\n",
>> 	    ofnode_get_name(node), *devp ? (*devp)->name : "(none)", ret);
>> diff --git a/include/dm/uclass.h b/include/dm/uclass.h
>> index 456eef7f2f31..b99e36485bc5 100644
>> --- a/include/dm/uclass.h
>> +++ b/include/dm/uclass.h
>> @@ -67,8 +67,10 @@ struct udevice;
>>   * @child_pre_probe: Called before a child in this uclass is probed
>>   * @child_post_probe: Called after a child in this uclass is probed
>>   * @init: Called to set up the uclass
>>   * @destroy: Called to destroy the uclass
>> + * @stub_drv_name: Name of a stub driver to use for devices that are not
>> + * supported by any other driver.
>>   * @priv_auto: If non-zero this is the size of the private data
>>   * to be allocated in the uclass's ->priv pointer. If zero, then the uclass
>>   * driver is responsible for allocating any data required.
>>   * @per_device_auto: Each device can hold private data owned
>> @@ -98,8 +100,9 @@ struct uclass_driver {
>> 	int (*child_pre_probe)(struct udevice *dev);
>> 	int (*child_post_probe)(struct udevice *dev);
>> 	int (*init)(struct uclass *class);
>> 	int (*destroy)(struct uclass *class);
>> +	const char *fallback_drv_name;
>> 	int priv_auto;
>> 	int per_device_auto;
>> 	int per_device_plat_auto;
>> 	int per_child_auto;
>>
>
Tom Rini May 3, 2024, 9:18 p.m. UTC | #6
On Fri, May 03, 2024 at 05:53:11PM +0200, Caleb Connolly wrote:
> Hi all,
> 
> Sorry for the slow follow-up.
> 
> On 11/04/2024 04:37, Sean Anderson wrote:
> > 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@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@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?
> 
> Yes, will do. I originally used "stub" but then decided "fallback" was
> better, but I think you're right that stub is the right way to go here. As I
> agree that "fallback" implies some kind of real implementation.
> > > 
> > 
> > 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.
> 
> I don't think either approach is significantly better from a developer
> perspective. With my patches if there a driver with a matching compatible
> available then you will NEVER bind the stub, even if probe fails on the real
> driver. With your proposal we'd have to remember to remove the compatible
> from the stub driver or risk the race condition when binding drivers.
> 
> There is another subtle but important difference if we were to use a
> compatible list in the stub. It turns out that CONFIG_OF_LIVE affects the
> bind behaviour - U-Boot won't try to bind the children of a node with no
> driver when using the livetree. This is arguably more "correct", as usually
> child devices depend on their parent, so we save some cycles by not binding
> unsupported devices.
> 
> But, the RPM clock controller which I originally implemented this feature
> for is such a case, this is the DT (simplified for brevity):
> 
> rpm: remoteproc {
>     compatible = "qcom,sm6115-rpm-proc", "qcom,rpm-proc";
> 
>     glink-edge {
>         compatible = "qcom,glink-rpm";
> 
>         rpm_requests: rpm-requests {
>             compatible = "qcom,rpm-sm6115";
> 
>             rpmcc: clock-controller {
>                 compatible = "qcom,rpmcc-sm6115", "qcom,rpmcc";
>             };
>     };
> };
> 
> With livetree (which we use on qcom) we would need to stub not just the
> rpmcc but also the rpm-requests, the glink bus, and the remoteproc (yeah
> these platforms are a bit silly, I know XD).
> 
> However with the fallback solution as implemented in these patches, we
> totally sidestep this issue by directly binding the node on-demand,
> something we can only safely do for a stub driver as we don't need the
> parent devices.
> 
> So I can either:
> 
> 1) Make OF_LIVE behave like flattree and descend into all nodes (I don't
> know if this would cause any issues, but I think the livetree behaviour is
> more "correct" tbh).
> 2) Add stubs for all 3 of the parent nodes (and manually maintain a table of
> compatibles for clock drivers we want to stub).
> 3) Stick with this approach of binding the stub as a last resort.
> 
> Obviously I've already put the time into 3, and that would still be my
> preferred approach, but I'm open to other ideas.

I don't like option 1 either. But I don't see why option 2 is worrisome?
Yes, if adding a real driver for something we had stubbed out, we will
need to remove the compatible string for the stub. But that shouldn't
happen often? And we can put in a debug level or similar print so that
if someone is at the point of adding a new driver that had been stubbed
out and didn't remove the compatible stub to start with it should show
up pretty quick in looking at logs?
diff mbox series

Patch

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
+	bool "Enable per-uclass fallback drivers"
+	depends on DM
+	help
+	  If a driver requests a resource (like a clock) from a node which
+	  isn't bound to a driver, the driver model will look for a fallback
+	  driver to "stub" the resource. These stubs usually do nothing and
+	  are therefore only suitable in instances where the resource is not
+	  required.
+
 endmenu
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index e46d5717aa62..91d3a48d77b8 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -378,8 +378,26 @@  int uclass_find_device_by_of_offset(enum uclass_id id, int node,
 
 	return -ENODEV;
 }
 
+static int uclass_bind_fallback(struct uclass *uc, ofnode node, struct udevice **devp)
+{
+	struct driver *drv;
+
+	log(LOGC_DM, LOGL_ERR, "   - binding fallback '%s' driver '%s'\n",
+	    uc->uc_drv->name, uc->uc_drv->fallback_drv_name);
+
+	drv = lists_driver_lookup_name(uc->uc_drv->fallback_drv_name);
+	if (!drv) {
+		log(LOGC_DM, LOGL_DEBUG, "   - Can't find stub driver '%s' for uclass '%s'\n",
+		    uc->uc_drv->fallback_drv_name, uc->uc_drv->name);
+		return -ENOENT;
+	}
+
+	return device_bind_with_driver_data(gd->dm_root, drv,
+					  ofnode_get_name(node), 0, node, devp);
+}
+
 int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
 				 struct udevice **devp)
 {
 	struct uclass *uc;
@@ -401,9 +419,13 @@  int uclass_find_device_by_ofnode(enum uclass_id id, ofnode node,
 			*devp = dev;
 			goto done;
 		}
 	}
-	ret = -ENODEV;
+
+	if (CONFIG_IS_ENABLED(FALLBACK_DRIVERS) && uc->uc_drv->fallback_drv_name)
+		ret = uclass_bind_fallback(uc, node, devp);
+	else
+		ret = -ENODEV;
 
 done:
 	log(LOGC_DM, LOGL_DEBUG, "   - result for %s: %s (ret=%d)\n",
 	    ofnode_get_name(node), *devp ? (*devp)->name : "(none)", ret);
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 456eef7f2f31..b99e36485bc5 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -67,8 +67,10 @@  struct udevice;
  * @child_pre_probe: Called before a child in this uclass is probed
  * @child_post_probe: Called after a child in this uclass is probed
  * @init: Called to set up the uclass
  * @destroy: Called to destroy the uclass
+ * @stub_drv_name: Name of a stub driver to use for devices that are not
+ * supported by any other driver.
  * @priv_auto: If non-zero this is the size of the private data
  * to be allocated in the uclass's ->priv pointer. If zero, then the uclass
  * driver is responsible for allocating any data required.
  * @per_device_auto: Each device can hold private data owned
@@ -98,8 +100,9 @@  struct uclass_driver {
 	int (*child_pre_probe)(struct udevice *dev);
 	int (*child_post_probe)(struct udevice *dev);
 	int (*init)(struct uclass *class);
 	int (*destroy)(struct uclass *class);
+	const char *fallback_drv_name;
 	int priv_auto;
 	int per_device_auto;
 	int per_device_plat_auto;
 	int per_child_auto;