From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] driver core: make deferring probe forever optional
Date: Tue, 1 May 2018 15:08:03 -0700 [thread overview]
Message-ID: <20180501220803.GB31900@kroah.com> (raw)
In-Reply-To: <20180501213114.20183-1-robh@kernel.org>
On Tue, May 01, 2018 at 04:31:14PM -0500, Rob Herring wrote:
> Deferred probe will currently wait forever on dependent devices to probe,
> but sometimes a driver will never exist. It's also not always critical for
> a driver to exist. Platforms can rely on default configuration from the
> bootloader or reset defaults for things such as pinctrl and power domains.
> This is often the case with initial platform support until various drivers
> get enabled. There's at least 2 scenarios where deferred probe can render
> a platform broken. Both involve using a DT which has more devices and
> dependencies than the kernel supports. The 1st case is a driver may be
> disabled in the kernel config. The 2nd case is the kernel version may
> simply not have the dependent driver. This can happen if using a newer DT
> (provided by firmware perhaps) with a stable kernel version.
>
> Unfortunately, this change breaks with modules as we have no way of
> knowing when modules are done loading. One possibility is to make this
> opt in or out based on compatible strings rather than at a subsystem level.
> Ideally this information could be extracted automatically somehow. OTOH,
> maybe the lists are pretty small. There's only a handful of subsystems
> that can be optional, and then only so many drivers in those that can be
> modules (at least for pinctrl, many drivers are built-in only).
>
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> This patch came out of a discussion on the ARM boot-architecture
> list[1] about DT forwards and backwards compatibility issues. There are
> issues with newer DTs breaking on older, stable kernels. Some of these
> are difficult to solve, but cases of optional devices not having
> kernel support should be solvable.
>
> I tested this on a RPi3 B with the pinctrl driver forced off. With this
> change, the MMC/SD and UART drivers can function without the pinctrl
> driver.
>
> Rob
>
> [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
>
> drivers/base/dd.c | 16 ++++++++++++++++
> drivers/pinctrl/devicetree.c | 2 +-
> include/linux/device.h | 2 ++
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index c9f54089429b..5848808b9d7a 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -226,6 +226,15 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +
> +int driver_deferred_probe_optional(void)
> +{
> + if (initcalls_done)
> + return -ENODEV;
> +
> + return -EPROBE_DEFER;
> +}
The name is ackward for this function, but I can't think of anything
better at the moment, sorry. However, the overall idea for this is
sane, no objection from me at all for this change.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Rob Herring <robh@kernel.org>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Grant Likely <grant.likely@arm.com>,
Linus Walleij <linus.walleij@linaro.org>,
Mark Brown <broonie@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
boot-architecture@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
Alexander Graf <agraf@suse.de>
Subject: Re: [RFC PATCH] driver core: make deferring probe forever optional
Date: Tue, 1 May 2018 15:08:03 -0700 [thread overview]
Message-ID: <20180501220803.GB31900@kroah.com> (raw)
In-Reply-To: <20180501213114.20183-1-robh@kernel.org>
On Tue, May 01, 2018 at 04:31:14PM -0500, Rob Herring wrote:
> Deferred probe will currently wait forever on dependent devices to probe,
> but sometimes a driver will never exist. It's also not always critical for
> a driver to exist. Platforms can rely on default configuration from the
> bootloader or reset defaults for things such as pinctrl and power domains.
> This is often the case with initial platform support until various drivers
> get enabled. There's at least 2 scenarios where deferred probe can render
> a platform broken. Both involve using a DT which has more devices and
> dependencies than the kernel supports. The 1st case is a driver may be
> disabled in the kernel config. The 2nd case is the kernel version may
> simply not have the dependent driver. This can happen if using a newer DT
> (provided by firmware perhaps) with a stable kernel version.
>
> Unfortunately, this change breaks with modules as we have no way of
> knowing when modules are done loading. One possibility is to make this
> opt in or out based on compatible strings rather than at a subsystem level.
> Ideally this information could be extracted automatically somehow. OTOH,
> maybe the lists are pretty small. There's only a handful of subsystems
> that can be optional, and then only so many drivers in those that can be
> modules (at least for pinctrl, many drivers are built-in only).
>
> Cc: Alexander Graf <agraf@suse.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> This patch came out of a discussion on the ARM boot-architecture
> list[1] about DT forwards and backwards compatibility issues. There are
> issues with newer DTs breaking on older, stable kernels. Some of these
> are difficult to solve, but cases of optional devices not having
> kernel support should be solvable.
>
> I tested this on a RPi3 B with the pinctrl driver forced off. With this
> change, the MMC/SD and UART drivers can function without the pinctrl
> driver.
>
> Rob
>
> [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
>
> drivers/base/dd.c | 16 ++++++++++++++++
> drivers/pinctrl/devicetree.c | 2 +-
> include/linux/device.h | 2 ++
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index c9f54089429b..5848808b9d7a 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -226,6 +226,15 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +
> +int driver_deferred_probe_optional(void)
> +{
> + if (initcalls_done)
> + return -ENODEV;
> +
> + return -EPROBE_DEFER;
> +}
The name is ackward for this function, but I can't think of anything
better at the moment, sorry. However, the overall idea for this is
sane, no objection from me at all for this change.
thanks,
greg k-h
next prev parent reply other threads:[~2018-05-01 22:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-01 21:31 [RFC PATCH] driver core: make deferring probe forever optional Rob Herring
2018-05-01 21:31 ` Rob Herring
2018-05-01 21:31 ` Rob Herring
2018-05-01 22:08 ` Greg Kroah-Hartman [this message]
2018-05-01 22:08 ` Greg Kroah-Hartman
2018-05-02 11:40 ` Robin Murphy
2018-05-02 11:40 ` Robin Murphy
2018-05-02 14:48 ` Rob Herring
2018-05-02 14:48 ` Rob Herring
2018-05-02 18:49 ` Robin Murphy
2018-05-02 18:49 ` Robin Murphy
2018-05-05 1:25 ` Mark Brown
2018-05-05 1:25 ` Mark Brown
2018-05-07 13:37 ` Rob Herring
2018-05-07 13:37 ` Rob Herring
2018-05-02 13:16 ` Alexander Graf
2018-05-02 13:16 ` Alexander Graf
2018-05-07 18:31 ` Bjorn Andersson
2018-05-07 18:31 ` Bjorn Andersson
2018-05-07 19:55 ` Rob Herring
2018-05-07 19:55 ` Rob Herring
2018-05-07 22:34 ` Bjorn Andersson
2018-05-07 22:34 ` Bjorn Andersson
2018-05-09 9:18 ` Mark Brown
2018-05-09 9:18 ` Mark Brown
2018-05-09 9:57 ` Alexander Graf
2018-05-09 9:57 ` Alexander Graf
2018-05-09 22:34 ` Rob Herring
2018-05-09 22:30 ` Rob Herring
2018-05-09 9:44 ` Alexander Graf
2018-05-09 9:44 ` Alexander Graf
2018-05-13 22:01 ` Linus Walleij
2018-05-13 22:01 ` Linus Walleij
2018-05-14 7:37 ` Alexander Graf
2018-05-14 7:37 ` Alexander Graf
2018-05-14 12:44 ` Michal Simek
2018-05-14 12:44 ` Michal Simek
2018-05-14 12:44 ` Michal Simek
2018-05-16 14:38 ` Linus Walleij
2018-05-16 14:38 ` Linus Walleij
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=20180501220803.GB31900@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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.