| Message ID | 20221116120159.519908-1-javierm@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | driver core: Decouple device links enforcing and probe deferral timeouts | expand |
Hi-- On 11/16/22 04:01, Javier Martinez Canillas wrote: > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index a465d5242774..38138a44d5ed 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1581,6 +1581,13 @@ > dependencies. This only applies for fw_devlink=on|rpm. > Format: <bool> > > + fw_devlink.timeout= > + [KNL] Debugging option to set a timeout in seconds for > + drivers to give up waiting on dependencies and to probe > + these are optional. A timeout of 0 will timeout at the > + end of initcalls. If the time out hasn't expired, it'll timeout > + be restarted by each successful driver registration.
On Wed, Nov 16, 2022 at 01:01:59PM +0100, Javier Martinez Canillas wrote: > Currently, the probe deferral timeout does two things: > > 1) Call to fw_devlink_drivers_done() to relax the device dependencies and > allow drivers to be probed if these dependencies are optional. > > 2) Disable the probe deferral mechanism so that drivers will fail to probe > if the required dependencies are not present, instead of adding them to > the deferred probe pending list. > > But there is no need to couple these two, for example the probe deferral > can be used even when the device links are disable (i.e: fw_devlink=off). > > So let's add a separate fw_devlink.timeout command line parameter to allow > relaxing the device links and prevent drivers to wait for these to probe. > > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > --- > > (no changes since v1) > > .../admin-guide/kernel-parameters.txt | 7 ++++ > drivers/base/dd.c | 38 ++++++++++++++++++- > 2 files changed, 44 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index a465d5242774..38138a44d5ed 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1581,6 +1581,13 @@ > dependencies. This only applies for fw_devlink=on|rpm. > Format: <bool> > > + fw_devlink.timeout= Just thought about this, but I think this should be called fw_devlink_timeout. Generally the $MODULE.$PARAM syntax is reserved for things that can be specificed with module_param(). The advantage is if you accidentally type say fw_devlink_timeut=10 the kernel logs will indicate it has no clue what that means. Including the "." makes the kernel assume that maybe a future module name fw_devlink will be loaded, and at that time will see if that module has the parameter mentioned. A little thing but I think work changing in v3. Thanks, Andrew
On Wed, Nov 16, 2022 at 4:02 AM Javier Martinez Canillas <javierm@redhat.com> wrote: > > Currently, the probe deferral timeout does two things: > > 1) Call to fw_devlink_drivers_done() to relax the device dependencies and > allow drivers to be probed if these dependencies are optional. > > 2) Disable the probe deferral mechanism so that drivers will fail to probe > if the required dependencies are not present, instead of adding them to > the deferred probe pending list. > > But there is no need to couple these two, for example the probe deferral > can be used even when the device links are disable (i.e: fw_devlink=off). > > So let's add a separate fw_devlink.timeout command line parameter to allow > relaxing the device links and prevent drivers to wait for these to probe. I'm probably being dim, but it's not immediately clear from this description *why* this is useful. Maybe add some words on the tangible benefit of splitting this up? I'd also push a little bit back on why we need to split this into a separate boot option. Since it's not obvious as to when a user would want to use fw_devlink.timeout vs probe_deferral_timeout. The extra complexity of remembering which timeout is for what might become a burden to users and developers. > > + fw_devlink.timeout= > + [KNL] Debugging option to set a timeout in seconds for > + drivers to give up waiting on dependencies and to probe > + these are optional. A timeout of 0 will timeout at the > + end of initcalls. If the time out hasn't expired, it'll > + be restarted by each successful driver registration. > + This sounds pretty close to like the deferred_probe_timeout option. I'd suggest some words to make the distinction more clear. thanks -john
Hello John, On 11/17/22 20:07, John Stultz wrote: > On Wed, Nov 16, 2022 at 4:02 AM Javier Martinez Canillas > <javierm@redhat.com> wrote: >> >> Currently, the probe deferral timeout does two things: >> >> 1) Call to fw_devlink_drivers_done() to relax the device dependencies and >> allow drivers to be probed if these dependencies are optional. >> >> 2) Disable the probe deferral mechanism so that drivers will fail to probe >> if the required dependencies are not present, instead of adding them to >> the deferred probe pending list. >> >> But there is no need to couple these two, for example the probe deferral >> can be used even when the device links are disable (i.e: fw_devlink=off). >> >> So let's add a separate fw_devlink.timeout command line parameter to allow >> relaxing the device links and prevent drivers to wait for these to probe. > > I'm probably being dim, but it's not immediately clear from this > description *why* this is useful. Maybe add some words on the tangible > benefit of splitting this up? > Thanks for your feedback. You are right that I need to better explain the why / goal of this patch. But basically is that it would be good to allow timeout waiting for the optional links while still allow the non-optional links to keep make the drivers to keep deferring. I can make a better job at explaining the why in the next iteration. > I'd also push a little bit back on why we need to split this into a > separate boot option. Since it's not obvious as to when a user would > want to use fw_devlink.timeout vs probe_deferral_timeout. > The extra complexity of remembering which timeout is for what might > become a burden to users and developers. > >> >> + fw_devlink.timeout= >> + [KNL] Debugging option to set a timeout in seconds for >> + drivers to give up waiting on dependencies and to probe >> + these are optional. A timeout of 0 will timeout at the >> + end of initcalls. If the time out hasn't expired, it'll >> + be restarted by each successful driver registration. >> + > > This sounds pretty close to like the deferred_probe_timeout option. > I'd suggest some words to make the distinction more clear. > Yeah, I can think how to better explain this... but it's similar because there is some overlapping between the two really, but are not exactly the same even though we are tying the two and folding the disable of the two under the same timeout. I'll be OK to drop this parameter btw, and just keep it as an internal var if it's fine to just always use the default 10 seconds or whatever timeout it is decided.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a465d5242774..38138a44d5ed 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1581,6 +1581,13 @@ dependencies. This only applies for fw_devlink=on|rpm. Format: <bool> + fw_devlink.timeout= + [KNL] Debugging option to set a timeout in seconds for + drivers to give up waiting on dependencies and to probe + these are optional. A timeout of 0 will timeout at the + end of initcalls. If the time out hasn't expired, it'll + be restarted by each successful driver registration. + gamecon.map[2|3]= [HW,JOY] Multisystem joystick and NES/SNES/PSX pad support via parallel port (up to 5 devices per port) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 1e8f1afeac98..ea448df94d24 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -261,6 +261,7 @@ static int driver_deferred_probe_timeout = 10; #else static int driver_deferred_probe_timeout; #endif +static int fw_devlink_timeout = -1; static int __init deferred_probe_timeout_setup(char *str) { @@ -272,6 +273,16 @@ static int __init deferred_probe_timeout_setup(char *str) } __setup("deferred_probe_timeout=", deferred_probe_timeout_setup); +static int __init fw_devlink_timeout_setup(char *str) +{ + int timeout; + + if (!kstrtoint(str, 10, &timeout)) + fw_devlink_timeout = timeout; + return 1; +} +__setup("fw_devlink.timeout=", fw_devlink_timeout_setup); + /** * driver_deferred_probe_check_state() - Check deferred probe state * @dev: device to check @@ -318,6 +329,15 @@ static void deferred_probe_timeout_work_func(struct work_struct *work) } static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func); +static void fw_devlink_timeout_work_func(struct work_struct *work) +{ + fw_devlink_drivers_done(); + + driver_deferred_probe_trigger(); + flush_work(&deferred_probe_work); +} +static DECLARE_DELAYED_WORK(fw_devlink_timeout_work, fw_devlink_timeout_work_func); + void deferred_probe_extend_timeout(void) { /* @@ -330,6 +350,13 @@ void deferred_probe_extend_timeout(void) pr_debug("Extended deferred probe timeout by %d secs\n", driver_deferred_probe_timeout); } + + if (cancel_delayed_work(&fw_devlink_timeout_work)) { + schedule_delayed_work(&fw_devlink_timeout_work, + fw_devlink_timeout * HZ); + pr_debug("Extended fw_devlink timeout by %d secs\n", + fw_devlink_timeout); + } } /** @@ -352,9 +379,12 @@ static int deferred_probe_initcall(void) if (!IS_ENABLED(CONFIG_MODULES)) { driver_deferred_probe_timeout = 0; - fw_devlink_drivers_done(); + fw_devlink_timeout = 0; } + if (!fw_devlink_timeout) + fw_devlink_drivers_done(); + /* * Trigger deferred probe again, this time we won't defer anything * that is optional @@ -366,6 +396,12 @@ static int deferred_probe_initcall(void) schedule_delayed_work(&deferred_probe_timeout_work, driver_deferred_probe_timeout * HZ); } + + if (fw_devlink_timeout > 0) { + schedule_delayed_work(&fw_devlink_timeout_work, + fw_devlink_timeout * HZ); + } + return 0; } late_initcall(deferred_probe_initcall);
Currently, the probe deferral timeout does two things: 1) Call to fw_devlink_drivers_done() to relax the device dependencies and allow drivers to be probed if these dependencies are optional. 2) Disable the probe deferral mechanism so that drivers will fail to probe if the required dependencies are not present, instead of adding them to the deferred probe pending list. But there is no need to couple these two, for example the probe deferral can be used even when the device links are disable (i.e: fw_devlink=off). So let's add a separate fw_devlink.timeout command line parameter to allow relaxing the device links and prevent drivers to wait for these to probe. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> --- (no changes since v1) .../admin-guide/kernel-parameters.txt | 7 ++++ drivers/base/dd.c | 38 ++++++++++++++++++- 2 files changed, 44 insertions(+), 1 deletion(-)