drivers/clk/imx/clk-imx8mp.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
We have an imx8mp-based board with an external gpio-triggered
watchdog. Currently, we don't get to handle that in time before it
resets the board.
The probe of the watchdog device gets deferred because the SOC's GPIO
controller is not yet ready, and the probe of that in turn gets deferred
because its clock provider (namely, this driver) is not yet
ready. Altogether, the watchdog does not get handled until the late
initcall deferred_probe_initcall has made sure all leftover devices
have been probed, and that's way too late.
Aside from being necessary for our board, this also reduces total boot
time because fewer device probes get deferred.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
It would probably be reasonable to do the same to the other imx8m* clk
drivers, but I don't have any such hardware to test on.
drivers/clk/imx/clk-imx8mp.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index e89db568f5a8..9ddd39a664cc 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -734,7 +734,19 @@ static struct platform_driver imx8mp_clk_driver = {
.of_match_table = imx8mp_clk_of_match,
},
};
-module_platform_driver(imx8mp_clk_driver);
+
+static int __init imx8mp_clk_init(void)
+{
+ return platform_driver_register(&imx8mp_clk_driver);
+}
+arch_initcall(imx8mp_clk_init);
+
+static void __exit imx8mp_clk_exit(void)
+{
+ platform_driver_unregister(&imx8mp_clk_driver);
+}
+module_exit(imx8mp_clk_exit);
+
module_param(mcore_booted, bool, S_IRUGO);
MODULE_PARM_DESC(mcore_booted, "See Cortex-M core is booted or not");
--
2.37.2
On 22-09-28 14:41:08, Rasmus Villemoes wrote: > We have an imx8mp-based board with an external gpio-triggered > watchdog. Currently, we don't get to handle that in time before it > resets the board. > > The probe of the watchdog device gets deferred because the SOC's GPIO > controller is not yet ready, and the probe of that in turn gets deferred > because its clock provider (namely, this driver) is not yet > ready. Altogether, the watchdog does not get handled until the late > initcall deferred_probe_initcall has made sure all leftover devices > have been probed, and that's way too late. > > Aside from being necessary for our board, this also reduces total boot > time because fewer device probes get deferred. > I'm gonna be honest here. I can't say I'm happy with this. I would suggest finding a solution to disable the external watchdog before booting the kernel, up until the driver probes, would be preferable to me. > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > --- > It would probably be reasonable to do the same to the other imx8m* clk > drivers, but I don't have any such hardware to test on. > > drivers/clk/imx/clk-imx8mp.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c > index e89db568f5a8..9ddd39a664cc 100644 > --- a/drivers/clk/imx/clk-imx8mp.c > +++ b/drivers/clk/imx/clk-imx8mp.c > @@ -734,7 +734,19 @@ static struct platform_driver imx8mp_clk_driver = { > .of_match_table = imx8mp_clk_of_match, > }, > }; > -module_platform_driver(imx8mp_clk_driver); > + > +static int __init imx8mp_clk_init(void) > +{ > + return platform_driver_register(&imx8mp_clk_driver); > +} > +arch_initcall(imx8mp_clk_init); > + > +static void __exit imx8mp_clk_exit(void) > +{ > + platform_driver_unregister(&imx8mp_clk_driver); > +} > +module_exit(imx8mp_clk_exit); > + > module_param(mcore_booted, bool, S_IRUGO); > MODULE_PARM_DESC(mcore_booted, "See Cortex-M core is booted or not"); > > -- > 2.37.2 >
On 21/11/2022 16.43, Abel Vesa wrote: > On 22-09-28 14:41:08, Rasmus Villemoes wrote: >> We have an imx8mp-based board with an external gpio-triggered >> watchdog. Currently, we don't get to handle that in time before it >> resets the board. >> >> The probe of the watchdog device gets deferred because the SOC's GPIO >> controller is not yet ready, and the probe of that in turn gets deferred >> because its clock provider (namely, this driver) is not yet >> ready. Altogether, the watchdog does not get handled until the late >> initcall deferred_probe_initcall has made sure all leftover devices >> have been probed, and that's way too late. >> >> Aside from being necessary for our board, this also reduces total boot >> time because fewer device probes get deferred. >> > > I'm gonna be honest here. I can't say I'm happy with this. > I would suggest finding a solution to disable the external watchdog > before booting the kernel, up until the driver probes, would be preferable > to me. That's not an option (it would violate the very purpose of having an external always-running watchdog), and also simply not possible on the given hardware. I don't understand why this simple patch can't just be applied. It hurts nothing, it makes all imx8mp boards boot very slightly faster, there's no maintenance burden associated with the boilerplate code, it allows hardware that already exists to actually work with a mainline kernel out-of-the-box. And in an alternate universe where the init function had been arch_initcall in the initial commit (such as those in drivers/clk/mediatek/), nobody would have asked any questions. Rasmus
Quoting Rasmus Villemoes (2022-11-21 23:49:50) > On 21/11/2022 16.43, Abel Vesa wrote: > > On 22-09-28 14:41:08, Rasmus Villemoes wrote: > >> We have an imx8mp-based board with an external gpio-triggered > >> watchdog. Currently, we don't get to handle that in time before it > >> resets the board. > >> > >> The probe of the watchdog device gets deferred because the SOC's GPIO > >> controller is not yet ready, and the probe of that in turn gets deferred > >> because its clock provider (namely, this driver) is not yet > >> ready. Altogether, the watchdog does not get handled until the late > >> initcall deferred_probe_initcall has made sure all leftover devices > >> have been probed, and that's way too late. > >> > >> Aside from being necessary for our board, this also reduces total boot > >> time because fewer device probes get deferred. > >> > > > > I'm gonna be honest here. I can't say I'm happy with this. > > I would suggest finding a solution to disable the external watchdog > > before booting the kernel, up until the driver probes, would be preferable > > to me. > > That's not an option (it would violate the very purpose of having an > external always-running watchdog), and also simply not possible on the > given hardware. > > I don't understand why this simple patch can't just be applied. It hurts > nothing, it makes all imx8mp boards boot very slightly faster, there's > no maintenance burden associated with the boilerplate code, There is a maintenance burden. Moving the initcall around is papering over the problem by not clearly describing the requirement to probe the watchdog driver as soon as possible. I don't expect to remember years from now that the watchdog driver needed this driver and the pinctrl driver to avoid probe defer, otherwise the watchdog will bite because it probes too late. The problem is not being solved directly. That's why we're concerned. Maybe if the problem statement was "don't allow probe defer", and that was worked into the driver core so drivers can be marked as "panic when this driver probe defers" then it would be more obvious what sort of behavior we don't want. Or to go further, maybe this board compatible needs to probe a board driver that only adds the clk, pinctrl, and watchdog devices as a first pass with a comment that these devices need to be probed as soon as possible to avoid watchdog bites on that board. Then once those devices are probed it can add the rest of the devices. > it allows > hardware that already exists to actually work with a mainline kernel > out-of-the-box. And in an alternate universe where the init function had > been arch_initcall in the initial commit (such as those in > drivers/clk/mediatek/), nobody would have asked any questions. > The usage of arch_initcall() and core_initcall() should be fixed.
On Wed, Sep 28, 2022 at 9:41 AM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > > We have an imx8mp-based board with an external gpio-triggered > watchdog. Currently, we don't get to handle that in time before it > resets the board. > > The probe of the watchdog device gets deferred because the SOC's GPIO > controller is not yet ready, and the probe of that in turn gets deferred > because its clock provider (namely, this driver) is not yet > ready. Altogether, the watchdog does not get handled until the late > initcall deferred_probe_initcall has made sure all leftover devices > have been probed, and that's way too late. > > Aside from being necessary for our board, this also reduces total boot > time because fewer device probes get deferred. > > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > --- > It would probably be reasonable to do the same to the other imx8m* clk > drivers, but I don't have any such hardware to test on. Agreed. > +static void __exit imx8mp_clk_exit(void) > +{ > + platform_driver_unregister(&imx8mp_clk_driver); > +} > +module_exit(imx8mp_clk_exit); Isn't module_exit() unnecessary here, since we pass suppress_bind_attrs = true? With module_exit() removed: Reviewed-by: Fabio Estevam <festevam@gmail.com>
On 19/11/2022 22.38, Fabio Estevam wrote: > On Wed, Sep 28, 2022 at 9:41 AM Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: >> >> We have an imx8mp-based board with an external gpio-triggered >> watchdog. Currently, we don't get to handle that in time before it >> resets the board. >> >> The probe of the watchdog device gets deferred because the SOC's GPIO >> controller is not yet ready, and the probe of that in turn gets deferred >> because its clock provider (namely, this driver) is not yet >> ready. Altogether, the watchdog does not get handled until the late >> initcall deferred_probe_initcall has made sure all leftover devices >> have been probed, and that's way too late. >> >> Aside from being necessary for our board, this also reduces total boot >> time because fewer device probes get deferred. >> >> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> >> --- >> It would probably be reasonable to do the same to the other imx8m* clk >> drivers, but I don't have any such hardware to test on. > > Agreed. > >> +static void __exit imx8mp_clk_exit(void) >> +{ >> + platform_driver_unregister(&imx8mp_clk_driver); >> +} >> +module_exit(imx8mp_clk_exit); > > Isn't module_exit() unnecessary here, since we pass suppress_bind_attrs = true? Sorry, I don't follow. Before this patch, the driver also implicitly had a module_exit() doing exactly this platform_driver_unregister(), it was just hidden inside the module_platform_driver() macro. And I think that's necessary if one wants to test that the module can be loaded and unloaded (I don't think it's ever useful or even possible to have it be a module on an actual imx8mp board). For a modular build, this patch changes nothing since all foo_initcall levels are translated to module_initcall for those. And when the driver is built-in, the __exit code, both before and after this patch, is discarded in the final image. Rasmus
On Sat, Nov 19, 2022 at 6:57 PM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > Sorry, I don't follow. Before this patch, the driver also implicitly had > a module_exit() doing exactly this platform_driver_unregister(), it was > just hidden inside the module_platform_driver() macro. And I think > that's necessary if one wants to test that the module can be loaded and > unloaded (I don't think it's ever useful or even possible to have it be > a module on an actual imx8mp board). You cannot load/unload it due to .suppress_bind_attrs = true, being passed. > For a modular build, this patch changes nothing since all foo_initcall > levels are translated to module_initcall for those. And when the driver > is built-in, the __exit code, both before and after this patch, is > discarded in the final image. All I am suggesting is that you the patch only does: --- a/drivers/clk/imx/clk-imx8mp.c +++ b/drivers/clk/imx/clk-imx8mp.c @@ -734,7 +734,19 @@ static struct platform_driver imx8mp_clk_driver = { .of_match_table = imx8mp_clk_of_match, }, }; -module_platform_driver(imx8mp_clk_driver); + +static int __init imx8mp_clk_init(void) +{ + return platform_driver_register(&imx8mp_clk_driver); +} +arch_initcall(imx8mp_clk_init); This is the same as in drivers/pinctrl/freescale/pinctrl-imx8mm.c for example.
On 19/11/2022 23.02, Fabio Estevam wrote: > On Sat, Nov 19, 2022 at 6:57 PM Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: > >> Sorry, I don't follow. Before this patch, the driver also implicitly had >> a module_exit() doing exactly this platform_driver_unregister(), it was >> just hidden inside the module_platform_driver() macro. And I think >> that's necessary if one wants to test that the module can be loaded and >> unloaded (I don't think it's ever useful or even possible to have it be >> a module on an actual imx8mp board). > > You cannot load/unload it due to .suppress_bind_attrs = true, being passed. That doesn't seem to be true. To test, I just built the imx8mq clk driver as a module, and I could certainly both load and unload that on my imx8mp platform. Sure, no "bind" attribute shows up in the /sys/bus/platform/drivers/imx8mq-ccm/ directory, which is exactly what one expects, but the module can be loaded just fine. And since it can be loaded, it should also have a proper __exit call for deregistering the driver on unload. Rasmus
On Mon, Nov 21, 2022 at 6:44 AM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > That doesn't seem to be true. To test, I just built the imx8mq clk > driver as a module, and I could certainly both load and unload that on > my imx8mp platform. Sure, no "bind" attribute shows up in the > /sys/bus/platform/drivers/imx8mq-ccm/ directory, which is exactly what > one expects, but the module can be loaded just fine. And since it can be > loaded, it should also have a proper __exit call for deregistering the > driver on unload. You are right. Sorry for the confusion.
On 21/11/2022 11.59, Fabio Estevam wrote: > On Mon, Nov 21, 2022 at 6:44 AM Rasmus Villemoes > <linux@rasmusvillemoes.dk> wrote: > >> That doesn't seem to be true. To test, I just built the imx8mq clk >> driver as a module, and I could certainly both load and unload that on >> my imx8mp platform. Sure, no "bind" attribute shows up in the >> /sys/bus/platform/drivers/imx8mq-ccm/ directory, which is exactly what >> one expects, but the module can be loaded just fine. And since it can be >> loaded, it should also have a proper __exit call for deregistering the >> driver on unload. > > You are right. Sorry for the confusion. Thanks. Does that mean I can keep your R-b for the patch as-is? Rasmus
On Mon, Nov 21, 2022 at 9:29 AM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > Thanks. Does that mean I can keep your R-b for the patch as-is? Yes, please keep it. Thanks
On 28/09/2022 14.41, Rasmus Villemoes wrote: > We have an imx8mp-based board with an external gpio-triggered > watchdog. Currently, we don't get to handle that in time before it > resets the board. > > The probe of the watchdog device gets deferred because the SOC's GPIO > controller is not yet ready, and the probe of that in turn gets deferred > because its clock provider (namely, this driver) is not yet > ready. Altogether, the watchdog does not get handled until the late > initcall deferred_probe_initcall has made sure all leftover devices > have been probed, and that's way too late. > > Aside from being necessary for our board, this also reduces total boot > time because fewer device probes get deferred. Please advise on what I need to do in order to make progress here. Thanks, Rasmus
On 07/11/2022 14.54, Rasmus Villemoes wrote: > On 28/09/2022 14.41, Rasmus Villemoes wrote: >> We have an imx8mp-based board with an external gpio-triggered >> watchdog. Currently, we don't get to handle that in time before it >> resets the board. >> >> The probe of the watchdog device gets deferred because the SOC's GPIO >> controller is not yet ready, and the probe of that in turn gets deferred >> because its clock provider (namely, this driver) is not yet >> ready. Altogether, the watchdog does not get handled until the late >> initcall deferred_probe_initcall has made sure all leftover devices >> have been probed, and that's way too late. >> >> Aside from being necessary for our board, this also reduces total boot >> time because fewer device probes get deferred. > > Please advise on what I need to do in order to make progress here. Ping.
Quoting Rasmus Villemoes (2022-09-28 05:41:08) > We have an imx8mp-based board with an external gpio-triggered > watchdog. Currently, we don't get to handle that in time before it > resets the board. How much time does your bootloader give you to pet the watchdog? Why is the timeout short enough to trigger? Or is deferring probe slowing down boot so significantly that boot times are bad? > > The probe of the watchdog device gets deferred because the SOC's GPIO > controller is not yet ready, and the probe of that in turn gets deferred > because its clock provider (namely, this driver) is not yet > ready. Altogether, the watchdog does not get handled until the late > initcall deferred_probe_initcall has made sure all leftover devices > have been probed, and that's way too late. > > Aside from being necessary for our board, this also reduces total boot > time because fewer device probes get deferred. This is a game of whack-a-mole. If we decide to move device population from DT (of_platform_default_populate_init) to device_initcall() level we may run into a similar problem. > > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > --- > It would probably be reasonable to do the same to the other imx8m* clk > drivers, but I don't have any such hardware to test on. > > drivers/clk/imx/clk-imx8mp.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c > index e89db568f5a8..9ddd39a664cc 100644 > --- a/drivers/clk/imx/clk-imx8mp.c > +++ b/drivers/clk/imx/clk-imx8mp.c > @@ -734,7 +734,19 @@ static struct platform_driver imx8mp_clk_driver = { > .of_match_table = imx8mp_clk_of_match, > }, > }; > -module_platform_driver(imx8mp_clk_driver); > + > +static int __init imx8mp_clk_init(void) > +{ > + return platform_driver_register(&imx8mp_clk_driver); > +} > +arch_initcall(imx8mp_clk_init); Furthermore, there isn't any comment about why this is arch_initcall level. The next reader of this code can only assume why this was done or go on a git archaeology dig to figure out that we're registering this device early for some imx8mp-based board (is it upstream? What board is it?). Please help people reading the code.
On 28/10/2022 01.29, Stephen Boyd wrote: > Quoting Rasmus Villemoes (2022-09-28 05:41:08) >> We have an imx8mp-based board with an external gpio-triggered >> watchdog. Currently, we don't get to handle that in time before it >> resets the board. > > How much time does your bootloader give you to pet the watchdog? The bootloader has no say; it's a simple piece of hardware with a hardcoded threshold. In this particular case 1 second. Most, if not all, custom designed industrial boards I've worked with has always been equipped with such an external watchdog (the threshold may be different, but the basic functionality and requirement is the same). In some cases, it's a matter of certifications, in others it's a requirement from certain end customers. But the hardware designers certainly never add this just for fun (obviously they want to keep complexity and BOM cost down). Why is > the timeout short enough to trigger? Or is deferring probe slowing down > boot so significantly that boot times are bad? I wouldn't say that deferring probe slows down the boot as such (it does, but not by a lot), but the fact that the watchdog device gets deferred (because it depends on the gpio and in turn the clk IP blocks in the SOC) is a problem. >> >> The probe of the watchdog device gets deferred because the SOC's GPIO >> controller is not yet ready, and the probe of that in turn gets deferred >> because its clock provider (namely, this driver) is not yet >> ready. Altogether, the watchdog does not get handled until the late >> initcall deferred_probe_initcall has made sure all leftover devices >> have been probed, and that's way too late. >> >> Aside from being necessary for our board, this also reduces total boot >> time because fewer device probes get deferred. > > This is a game of whack-a-mole. If we decide to move device population > from DT (of_platform_default_populate_init) to device_initcall() level > we may run into a similar problem. That's a red herring, because such a patch would be a regression for a lot of existing and working boards with an external gpio-wdt watchdog. >> >> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> >> --- >> It would probably be reasonable to do the same to the other imx8m* clk >> drivers, but I don't have any such hardware to test on. >> >> drivers/clk/imx/clk-imx8mp.c | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c >> index e89db568f5a8..9ddd39a664cc 100644 >> --- a/drivers/clk/imx/clk-imx8mp.c >> +++ b/drivers/clk/imx/clk-imx8mp.c >> @@ -734,7 +734,19 @@ static struct platform_driver imx8mp_clk_driver = { >> .of_match_table = imx8mp_clk_of_match, >> }, >> }; >> -module_platform_driver(imx8mp_clk_driver); >> + >> +static int __init imx8mp_clk_init(void) >> +{ >> + return platform_driver_register(&imx8mp_clk_driver); >> +} >> +arch_initcall(imx8mp_clk_init); > > Furthermore, there isn't any comment about why this is arch_initcall > level. The next reader of this code can only assume why this was done or > go on a git archaeology dig to figure out that we're registering this > device early for some imx8mp-based board (is it upstream? What board is > it?). Please help people reading the code. Sure, I could add a comment here. But if we take a step back, doesn't it make sense in general to make sure a central IP block like the SOC's primary clk source is probed early, before various other dependent IP blocks and peripherals? Initializing such a core part of the SOC certainly sounds to me like an arch-level thing. And it's not like this would be the first SOC-specific clk driver with init called at arch_initcall, without any comment why it happens at that time. E.g. clk_mt7629_init. IMO, that doesn't require a comment, it's really just common sense. As I said, I think this change would make sense for at least all the imx8m drivers, and I'm happy to extend the patch to cover those for consistency. It also gives a small but measurable improvement in total boot time, but that by itself is not why I want to make this change - it's simply a necessary patch to make my customer's new imx8mp-based boards boot. Rasmus
On 28/09/2022 14.41, Rasmus Villemoes wrote: > We have an imx8mp-based board with an external gpio-triggered > watchdog. Currently, we don't get to handle that in time before it > resets the board. > > The probe of the watchdog device gets deferred because the SOC's GPIO > controller is not yet ready, and the probe of that in turn gets deferred > because its clock provider (namely, this driver) is not yet > ready. Altogether, the watchdog does not get handled until the late > initcall deferred_probe_initcall has made sure all leftover devices > have been probed, and that's way too late. > > Aside from being necessary for our board, this also reduces total boot > time because fewer device probes get deferred. ping Rasmus
Hello Rasmus, On 24.10.22 15:48, Rasmus Villemoes wrote: > On 28/09/2022 14.41, Rasmus Villemoes wrote: >> We have an imx8mp-based board with an external gpio-triggered >> watchdog. Currently, we don't get to handle that in time before it >> resets the board. >> >> The probe of the watchdog device gets deferred because the SOC's GPIO >> controller is not yet ready, and the probe of that in turn gets deferred >> because its clock provider (namely, this driver) is not yet >> ready. Altogether, the watchdog does not get handled until the late >> initcall deferred_probe_initcall has made sure all leftover devices >> have been probed, and that's way too late. >> >> Aside from being necessary for our board, this also reduces total boot >> time because fewer device probes get deferred. > > ping Module build is unaffected, because arch_initcall expands to module_init if it's built as a module, right? Noting that in the commit message would be good I think. Also, did you try booting with fw_devlink=on? This should have resolved your issue too. Not sure what other issues it may cause on i.MX8MP. Cheers, Ahmad > > Rasmus > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 24/10/2022 16.00, Ahmad Fatoum wrote: > Hello Rasmus, > > On 24.10.22 15:48, Rasmus Villemoes wrote: >> On 28/09/2022 14.41, Rasmus Villemoes wrote: >>> We have an imx8mp-based board with an external gpio-triggered >>> watchdog. Currently, we don't get to handle that in time before it >>> resets the board. >>> >>> The probe of the watchdog device gets deferred because the SOC's GPIO >>> controller is not yet ready, and the probe of that in turn gets deferred >>> because its clock provider (namely, this driver) is not yet >>> ready. Altogether, the watchdog does not get handled until the late >>> initcall deferred_probe_initcall has made sure all leftover devices >>> have been probed, and that's way too late. >>> >>> Aside from being necessary for our board, this also reduces total boot >>> time because fewer device probes get deferred. >> >> ping > > Module build is unaffected, because arch_initcall expands to module_init > if it's built as a module, right? Yes. Noting that in the commit message would > be good I think. > > Also, did you try booting with fw_devlink=on? This should have resolved > your issue too. Not sure what other issues it may cause on i.MX8MP. AFAICT, that's the default behaviour: drivers/base/core.c:static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_ON; drivers/base/core.c-static int __init fw_devlink_setup(char *arg) drivers/base/core.c-{ drivers/base/core.c- if (!arg) drivers/base/core.c- return -EINVAL; drivers/base/core.c- drivers/base/core.c- if (strcmp(arg, "off") == 0) { drivers/base/core.c: fw_devlink_flags = 0; drivers/base/core.c- } else if (strcmp(arg, "permissive") == 0) { drivers/base/core.c: fw_devlink_flags = FW_DEVLINK_FLAGS_PERMISSIVE; drivers/base/core.c- } else if (strcmp(arg, "on") == 0) { drivers/base/core.c: fw_devlink_flags = FW_DEVLINK_FLAGS_ON; drivers/base/core.c- } else if (strcmp(arg, "rpm") == 0) { drivers/base/core.c: fw_devlink_flags = FW_DEVLINK_FLAGS_RPM; drivers/base/core.c- } drivers/base/core.c- return 0; drivers/base/core.c-} drivers/base/core.c-early_param("fw_devlink", fw_devlink_setup); But I don't think the problem is that the driver core has inferred the dependency chain upfront from parsing DT; the problem is simply that we end up probing the clock controller, and hence all dependencies too late. Rasmus
© 2016 - 2024 Red Hat, Inc.