[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180524181834.GF4828@sirena.org.uk>
Date: Thu, 24 May 2018 19:18:34 +0100
From: Mark Brown <broonie@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Walleij <linus.walleij@...aro.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>,
Frank Rowand <frowand.list@...il.com>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
boot-architecture@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/8] driver core: make deferring probe after init
optional
On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
> Subsystems or drivers may opt-in to this behavior by calling
> driver_deferred_probe_check_init_done() instead of just returning
> -EPROBE_DEFER. They may use additional information from DT or kernel's
> config to decide whether to continue to defer probe or not.
Should userspace have some involvement in this decision? It knows if
it's got any intention of loading modules for example. Kernel config
checks might be good enough, though it's going to be a pain to work out
if the relevant driver is built as a module for example.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists