| Message ID | 20240410-b4-stub-drivers-v1-1-6935bd2c07d1@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | dm: add support for stubbing optional devices | expand |
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; >
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?
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
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
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; >> >
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 --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;
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(-)