[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZU50xG-seDq8pZ0QLBXzn_Ygs-s1rJXGqzpfDJGbjDtA@mail.gmail.com>
Date: Mon, 2 Jul 2018 15:23:08 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Rob Herring <robh@...nel.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Alexander Graf <agraf@...e.de>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Kevin Hilman <khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Joerg Roedel <joro@...tes.org>,
Robin Murphy <robin.murphy@....com>,
Mark Brown <broonie@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, boot-architecture@...ts.linaro.org,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 3/6] pinctrl: Support stopping deferred probe after initcalls
On Thu, Jun 28, 2018 at 10:43 PM Rob Herring <robh@...nel.org> wrote:
> Pinctrl drivers are a common dependency which can prevent a system
> booting even if the default or bootloader configured settings can work.
> If a pinctrl node in DT indicates that the default pin setup can be used
> with the 'pinctrl-use-default' property, then only defer probe until
> initcalls are done. If the deferred probe timeout is enabled or loadable
> modules are disabled, then we'll stop deferring probe regardless of the
> DT property. This gives platforms the option to work without their
> pinctrl driver being enabled.
>
> Dropped the pinctrl specific deferring probe message as the driver core
> can print deferred probe related messages if needed.
>
> Signed-off-by: Rob Herring <robh@...nel.org>
> ---
> v3:
> - Drop pinctrl deferred probe msg in favor of driver core messages
> - Move the handling of "pinctrl-use-default" option out of driver core
> - Stop deferring probe if modules are not enabled.
>
> Linus, I reworked this a bit, so didn't add your ack.
Looks even better now:
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
Yours,
Linus Walleij
Powered by blists - more mailing lists