[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200218235730.GP4232@sirena.org.uk>
Date: Tue, 18 Feb 2020 23:57:30 +0000
From: Mark Brown <broonie@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: John Stultz <john.stultz@...aro.org>,
lkml <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Kevin Hilman <khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
Todd Kjos <tkjos@...gle.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"open list:THERMAL" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] driver core: Rework logic in
__driver_deferred_probe_check_state to allow EPROBE_DEFER to be returned for
longer
On Tue, Feb 18, 2020 at 05:53:01PM -0600, Rob Herring wrote:
> On Tue, Feb 18, 2020 at 5:21 PM John Stultz <john.stultz@...aro.org> wrote:
> > As long as 30 seconds is working well, I'm ok with it for now (and it
> > can be overrided via boot arg). Though from past experience with
> > enterprise distros running on servers with tons of disks (which might
> > take many minutes to initialize), I'd suspect its likely some
> > environments may need much longer.
> Those systems aren't going to have a pinctrl or clock driver sitting
> in an encrypted RAID partition either. :)
There speaks the voice of hope and optimism.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists