From: Mark Brown <broonie@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Rob Herring <robh@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Will Deacon <will@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Kevin Hilman <khilman@kernel.org>,
Thierry Reding <treding@nvidia.com>, Pavel Machek <pavel@ucw.cz>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org,
iommu@lists.linux-foundation.org, kernel-team@android.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration
Date: Fri, 13 May 2022 13:48:51 +0100 [thread overview]
Message-ID: <Yn5Ts1+56rBip8Mc@sirena.org.uk> (raw)
In-Reply-To: <20220429220933.1350374-1-saravanak@google.com>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
On Fri, Apr 29, 2022 at 03:09:32PM -0700, Saravana Kannan wrote:
> The deferred probe timer that's used for this currently starts at
> late_initcall and runs for driver_deferred_probe_timeout seconds. The
> assumption being that all available drivers would be loaded and
> registered before the timer expires. This means, the
> driver_deferred_probe_timeout has to be pretty large for it to cover the
> worst case. But if we set the default value for it to cover the worst
> case, it would significantly slow down the average case. For this
> reason, the default value is set to 0.
This makes sense to me.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Rob Herring <robh@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
kernel-team@android.com, linux-doc@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Walleij <linus.walleij@linaro.org>,
Jonathan Corbet <corbet@lwn.net>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
Kevin Hilman <khilman@kernel.org>,
iommu@lists.linux-foundation.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Pavel Machek <pavel@ucw.cz>,
linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org,
Thierry Reding <treding@nvidia.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration
Date: Fri, 13 May 2022 13:48:51 +0100 [thread overview]
Message-ID: <Yn5Ts1+56rBip8Mc@sirena.org.uk> (raw)
In-Reply-To: <20220429220933.1350374-1-saravanak@google.com>
[-- Attachment #1.1: Type: text/plain, Size: 653 bytes --]
On Fri, Apr 29, 2022 at 03:09:32PM -0700, Saravana Kannan wrote:
> The deferred probe timer that's used for this currently starts at
> late_initcall and runs for driver_deferred_probe_timeout seconds. The
> assumption being that all available drivers would be loaded and
> registered before the timer expires. This means, the
> driver_deferred_probe_timeout has to be pretty large for it to cover the
> worst case. But if we set the default value for it to cover the worst
> case, it would significantly slow down the average case. For this
> reason, the default value is set to 0.
This makes sense to me.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-05-13 12:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 22:09 [PATCH v1] driver core: Extend deferred probe timeout on driver registration Saravana Kannan
2022-04-29 22:09 ` Saravana Kannan via iommu
2022-05-13 12:48 ` Mark Brown [this message]
2022-05-13 12:48 ` Mark Brown
2022-05-13 13:58 ` Rob Herring
2022-05-13 13:58 ` Rob Herring
2022-05-13 17:25 ` Saravana Kannan
2022-05-13 17:25 ` Saravana Kannan via iommu
2022-05-16 13:49 ` Rob Herring
2022-05-16 13:49 ` Rob Herring
2022-05-20 23:30 ` Nathan Chancellor
2022-05-20 23:30 ` Nathan Chancellor
2022-05-20 23:49 ` Saravana Kannan
2022-05-20 23:49 ` Saravana Kannan via iommu
2022-05-21 0:04 ` Nathan Chancellor
2022-05-21 0:04 ` Nathan Chancellor
2022-05-21 0:15 ` Saravana Kannan
2022-05-21 0:15 ` Saravana Kannan via iommu
2022-05-23 15:17 ` Nathan Chancellor
2022-05-23 15:17 ` Nathan Chancellor
2022-05-23 20:04 ` Saravana Kannan
2022-05-23 20:04 ` Saravana Kannan via iommu
2022-05-23 22:14 ` Nathan Chancellor
2022-05-23 22:14 ` Nathan Chancellor
2022-05-24 3:43 ` Saravana Kannan
2022-05-24 3:43 ` Saravana Kannan via iommu
2022-05-24 16:41 ` Sebastian Andrzej Siewior
2022-05-24 16:41 ` Sebastian Andrzej Siewior
2022-05-24 17:46 ` Saravana Kannan
2022-05-24 17:46 ` Saravana Kannan via iommu
2022-05-25 7:11 ` Sebastian Andrzej Siewior
2022-05-25 7:11 ` Sebastian Andrzej Siewior
2022-05-25 19:49 ` Saravana Kannan
2022-05-25 19:49 ` Saravana Kannan via iommu
2022-05-29 8:34 ` Niklas Cassel
2022-05-29 8:34 ` Niklas Cassel via iommu
2022-05-30 4:59 ` Saravana Kannan
2022-05-30 4:59 ` Saravana Kannan via iommu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yn5Ts1+56rBip8Mc@sirena.org.uk \
--to=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kernel-team@android.com \
--cc=khilman@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=paul.kocialkowski@bootlin.com \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=treding@nvidia.com \
--cc=ulf.hansson@linaro.org \
--cc=will@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.