From: Bjorn Andersson <bjorn.andersson@linaro.org> To: Rob Herring <robh@kernel.org> Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.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: Mon, 7 May 2018 11:31:06 -0700 [thread overview] Message-ID: <20180507183106.GF2259@tuxbook-pro> (raw) In-Reply-To: <20180501213114.20183-1-robh@kernel.org> On Tue 01 May 14:31 PDT 2018, 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. But how do you know if this is the case? > This is often the case with initial platform support until various drivers > get enabled. Can you please name platform that has enough support for Alexander to care about backwards and forwards compatibility but lacks a pinctrl driver. > 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. I agree that there is a chance that you _might_ get some parts of the system working by relying on the boot loader configuration, but misconfiguration issues applies to any other fundamental providers, such as clocks, regulators, power domains and gpios as well. > 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. > As above, this is in no way limited to pinctrl drivers. > 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). > On the Qualcomm platform most drivers are tristate and on most platforms there are size restrictions in the proprietary boot loader preventing us from boot the kernel after switching all these frameworks from tristate to bool (which feels like a more appropriate solution than your hack). > 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. > There are two cases here: 1) DT contains compatibles that isn't supported by the kernel. In this case the associated device will remain in the probe deferral list and user space won't know about the device. 2) DT contains compatibles known to the kernel but has new optional properties that makes things functional or works around hardware bugs. > 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. > Cool, so what about graphics, audio, networking, usb and all the other things that people actually expect when they _use_ a distro? > 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; You forgot the humongous printout here that tells the users that we do not want any bug reports related hardware not working as expected after this point. > + > + return -EPROBE_DEFER; > +} > + I do not agree with the partial benefits of this at the cost of not supporting kernel modules. Regards, Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: bjorn.andersson@linaro.org (Bjorn Andersson) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH] driver core: make deferring probe forever optional Date: Mon, 7 May 2018 11:31:06 -0700 [thread overview] Message-ID: <20180507183106.GF2259@tuxbook-pro> (raw) In-Reply-To: <20180501213114.20183-1-robh@kernel.org> On Tue 01 May 14:31 PDT 2018, 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. But how do you know if this is the case? > This is often the case with initial platform support until various drivers > get enabled. Can you please name platform that has enough support for Alexander to care about backwards and forwards compatibility but lacks a pinctrl driver. > 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. I agree that there is a chance that you _might_ get some parts of the system working by relying on the boot loader configuration, but misconfiguration issues applies to any other fundamental providers, such as clocks, regulators, power domains and gpios as well. > 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. > As above, this is in no way limited to pinctrl drivers. > 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). > On the Qualcomm platform most drivers are tristate and on most platforms there are size restrictions in the proprietary boot loader preventing us from boot the kernel after switching all these frameworks from tristate to bool (which feels like a more appropriate solution than your hack). > 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. > There are two cases here: 1) DT contains compatibles that isn't supported by the kernel. In this case the associated device will remain in the probe deferral list and user space won't know about the device. 2) DT contains compatibles known to the kernel but has new optional properties that makes things functional or works around hardware bugs. > 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. > Cool, so what about graphics, audio, networking, usb and all the other things that people actually expect when they _use_ a distro? > 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; You forgot the humongous printout here that tells the users that we do not want any bug reports related hardware not working as expected after this point. > + > + return -EPROBE_DEFER; > +} > + I do not agree with the partial benefits of this at the cost of not supporting kernel modules. Regards, Bjorn
next prev parent reply other threads:[~2018-05-07 18:31 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 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 [this message] 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=20180507183106.GF2259@tuxbook-pro \ --to=bjorn.andersson@linaro.org \ --cc=agraf@suse.de \ --cc=boot-architecture@lists.linaro.org \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robh@kernel.org \ --cc=sboyd@kernel.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: linkBe 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.