From: "Rafael J. Wysocki" <rjw@rjwysocki.net> To: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: "Rob Herring" <robherring2@gmail.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "Alexander Holler" <holler@ahsoftware.de>, "Alexandre Courbot" <gnurou@gmail.com>, "Andrzej Hajda" <a.hajda@samsung.com>, "Arnd Bergmann" <arnd@arndb.de>, "Dmitry Torokhov" <dmitry.torokhov@gmail.com>, "Grant Likely" <grant.likely@linaro.org>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Ian Campbell" <ijc+devicetree@hellion.org.uk>, "Javier Martinez Canillas" <javier.martinez@collabora.co.uk>, "Krzysztof Kozlowski" <k.kozlowski@samsung.com>, "Kumar Gala" <galak@codeaurora.org>, "Len Brown" <lenb@kernel.org>, "Linus Walleij" <linus.walleij@linaro.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Lv Zheng" <lv.zheng@intel.com>, "Mark Brown" <broonie@kernel.org>, "Mark Rutland" <mark.rutland@arm.com>, "Pawel Moll" <pawel.moll@arm.com>, "Robert Moore" <robert.moore@intel.com>, "Rob Herring" <robh+dt@kernel.org>, "Russell King" <linux@arm.linux.org.uk>, "Stephen Warren" <swarren@wwwdotorg.org>, "Terje Bergström" <tbergstrom@nvidia.com>, "Thierry Reding" <thierry.reding@gmail.com> Subject: Re: [PATCH 02/13] driver-core: defer all probes until late_initcall Date: Tue, 23 Jun 2015 16:51:11 +0200 [thread overview] Message-ID: <1513496.zoUTpU2Ou0@vostro.rjw.lan> (raw) In-Reply-To: <CAAObsKAMn6xSs4-NCmvXO=EccXxdhv_Y4+KeYJ0Wj3Q5NHsYRg@mail.gmail.com> On Tuesday, June 23, 2015 04:17:29 PM Tomeu Vizoso wrote: > On 23 June 2015 at 16:37, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Monday, June 22, 2015 07:07:08 PM Rob Herring wrote: > >> On Fri, Jun 19, 2015 at 6:20 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> > On Friday, June 19, 2015 03:36:46 PM Tomeu Vizoso wrote: > >> >> On 18 June 2015 at 23:50, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> >> > On Wednesday, June 17, 2015 03:42:12 PM Tomeu Vizoso wrote: > >> >> >> To decrease the chances of devices deferring their probes because of > >> >> >> dependencies not having probed yet because of their drivers not having > >> >> >> registered yet, delay all probing until the late initcall level. > >> >> >> > >> >> >> This will allow us to avoid deferred probes completely later by probing > >> >> >> dependencies on demand, or by probing them in dependency order. > >> >> >> > >> >> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> > >> >> >> --- > >> >> >> drivers/base/dd.c | 8 +++++++- > >> >> >> 1 file changed, 7 insertions(+), 1 deletion(-) > >> >> >> > >> >> >> diff --git a/drivers/base/dd.c b/drivers/base/dd.c > >> >> >> index a638bbb..18438aa 100644 > >> >> >> --- a/drivers/base/dd.c > >> >> >> +++ b/drivers/base/dd.c > >> >> >> @@ -407,6 +407,12 @@ int driver_probe_device(struct device_driver *drv, struct device *dev) > >> >> >> if (!device_is_registered(dev)) > >> >> >> return -ENODEV; > >> >> >> > >> >> >> + /* Defer all probes until we start processing the queue */ > >> >> >> + if (!driver_deferred_probe_enable) { > >> >> >> + driver_deferred_probe_add(dev); > >> >> > > >> >> > Do I think correctly that this will effectively force everybody to use deferred > >> >> > probing? > >> >> > >> >> Guess it depends on the meaning of "using deferred probing". It will > >> >> defer the probe of the first device to late_initcall (which will > >> >> happen much earlier in time than before), but afterwards all built-in > >> >> drivers will be available and depending on the order in which we try > >> >> to probe devices, none may actually ask to defer its probe. > >> > > >> > So this will break things like the PNP system driver which relies on probing > >> > stuff at the fs_initcall stage for correctness. It may also break other > >> > things with similar assumptions. > >> > >> Yes, but I think that this can be done for only OF based devices > >> rather than globally for all platform devices and solve that problem. > >> Matching is already dependent of the type of device. > > > > Well, the current patch is not OF-only, though. > > Yeah, I'm currently looking at only delaying probing of devices > created from OF data. I'm not sure if tying it hard to OF is not too restrictive. Maybe we can use some general opt-in mechanism that OF will just always use? In fact, we have a similar problem in ACPI where we have the _DEP object which is used by firmware to describe dependencies between devices. > Note that calculating dependencies and trying to probe them before > they are needed can be done independently of this patch, but it isn't > that useful because devices will still defer their probes because the > drivers of some dependencies won't have been registered until > late_initcall. I see. Rafael
WARNING: multiple messages have this Message-ID (diff)
From: rjw@rjwysocki.net (Rafael J. Wysocki) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 02/13] driver-core: defer all probes until late_initcall Date: Tue, 23 Jun 2015 16:51:11 +0200 [thread overview] Message-ID: <1513496.zoUTpU2Ou0@vostro.rjw.lan> (raw) In-Reply-To: <CAAObsKAMn6xSs4-NCmvXO=EccXxdhv_Y4+KeYJ0Wj3Q5NHsYRg@mail.gmail.com> On Tuesday, June 23, 2015 04:17:29 PM Tomeu Vizoso wrote: > On 23 June 2015 at 16:37, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Monday, June 22, 2015 07:07:08 PM Rob Herring wrote: > >> On Fri, Jun 19, 2015 at 6:20 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> > On Friday, June 19, 2015 03:36:46 PM Tomeu Vizoso wrote: > >> >> On 18 June 2015 at 23:50, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> >> > On Wednesday, June 17, 2015 03:42:12 PM Tomeu Vizoso wrote: > >> >> >> To decrease the chances of devices deferring their probes because of > >> >> >> dependencies not having probed yet because of their drivers not having > >> >> >> registered yet, delay all probing until the late initcall level. > >> >> >> > >> >> >> This will allow us to avoid deferred probes completely later by probing > >> >> >> dependencies on demand, or by probing them in dependency order. > >> >> >> > >> >> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> > >> >> >> --- > >> >> >> drivers/base/dd.c | 8 +++++++- > >> >> >> 1 file changed, 7 insertions(+), 1 deletion(-) > >> >> >> > >> >> >> diff --git a/drivers/base/dd.c b/drivers/base/dd.c > >> >> >> index a638bbb..18438aa 100644 > >> >> >> --- a/drivers/base/dd.c > >> >> >> +++ b/drivers/base/dd.c > >> >> >> @@ -407,6 +407,12 @@ int driver_probe_device(struct device_driver *drv, struct device *dev) > >> >> >> if (!device_is_registered(dev)) > >> >> >> return -ENODEV; > >> >> >> > >> >> >> + /* Defer all probes until we start processing the queue */ > >> >> >> + if (!driver_deferred_probe_enable) { > >> >> >> + driver_deferred_probe_add(dev); > >> >> > > >> >> > Do I think correctly that this will effectively force everybody to use deferred > >> >> > probing? > >> >> > >> >> Guess it depends on the meaning of "using deferred probing". It will > >> >> defer the probe of the first device to late_initcall (which will > >> >> happen much earlier in time than before), but afterwards all built-in > >> >> drivers will be available and depending on the order in which we try > >> >> to probe devices, none may actually ask to defer its probe. > >> > > >> > So this will break things like the PNP system driver which relies on probing > >> > stuff at the fs_initcall stage for correctness. It may also break other > >> > things with similar assumptions. > >> > >> Yes, but I think that this can be done for only OF based devices > >> rather than globally for all platform devices and solve that problem. > >> Matching is already dependent of the type of device. > > > > Well, the current patch is not OF-only, though. > > Yeah, I'm currently looking at only delaying probing of devices > created from OF data. I'm not sure if tying it hard to OF is not too restrictive. Maybe we can use some general opt-in mechanism that OF will just always use? In fact, we have a similar problem in ACPI where we have the _DEP object which is used by firmware to describe dependencies between devices. > Note that calculating dependencies and trying to probe them before > they are needed can be done independently of this patch, but it isn't > that useful because devices will still defer their probes because the > drivers of some dependencies won't have been registered until > late_initcall. I see. Rafael
next prev parent reply other threads:[~2015-06-23 14:25 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-06-17 13:42 [PATCH 00/13] Discover and probe dependencies Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 01/13] gpiolib: Fix docs for gpiochip_add_pingroup_range Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-07-13 12:16 ` Linus Walleij 2015-07-13 12:16 ` Linus Walleij 2015-06-17 13:42 ` [PATCH 02/13] driver-core: defer all probes until late_initcall Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-18 21:50 ` Rafael J. Wysocki 2015-06-18 21:50 ` Rafael J. Wysocki 2015-06-19 13:36 ` Tomeu Vizoso 2015-06-19 13:36 ` Tomeu Vizoso 2015-06-19 23:20 ` Rafael J. Wysocki 2015-06-19 23:20 ` Rafael J. Wysocki 2015-06-23 0:07 ` Rob Herring 2015-06-23 0:07 ` Rob Herring 2015-06-23 14:37 ` Rafael J. Wysocki 2015-06-23 14:37 ` Rafael J. Wysocki 2015-06-23 14:17 ` Tomeu Vizoso 2015-06-23 14:17 ` Tomeu Vizoso 2015-06-23 14:51 ` Rafael J. Wysocki [this message] 2015-06-23 14:51 ` Rafael J. Wysocki 2015-06-23 14:37 ` Tomeu Vizoso 2015-06-23 14:37 ` Tomeu Vizoso 2015-06-24 0:14 ` Rafael J. Wysocki 2015-06-24 0:14 ` Rafael J. Wysocki 2015-06-17 13:42 ` [PATCH 03/13] ARM: tegra: Add gpio-ranges property Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 17:25 ` Mark Brown 2015-06-17 17:25 ` Mark Brown 2015-06-18 8:06 ` Tomeu Vizoso 2015-06-18 8:06 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 04/13] pinctrl: tegra: Only set the gpio range if needed Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-07-13 20:14 ` Linus Walleij 2015-07-13 20:14 ` Linus Walleij 2015-07-14 8:34 ` Tomeu Vizoso 2015-07-14 8:34 ` Tomeu Vizoso 2015-07-15 3:17 ` Alexandre Courbot 2015-07-15 3:17 ` Alexandre Courbot 2015-07-15 8:13 ` Tomeu Vizoso 2015-07-15 8:13 ` Tomeu Vizoso 2015-07-17 8:04 ` Linus Walleij 2015-07-17 8:04 ` Linus Walleij 2015-07-17 8:19 ` Tomeu Vizoso 2015-07-17 8:19 ` Tomeu Vizoso 2015-07-17 9:36 ` Linus Walleij 2015-07-17 9:36 ` Linus Walleij 2015-06-17 13:42 ` [PATCH 05/13] driver core: fix docbook for device_private.device Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 06/13] of/platform: Set fwnode field for new devices Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 17:27 ` Mark Brown 2015-06-17 17:27 ` Mark Brown 2015-06-17 13:42 ` [PATCH 07/13] driver-core: Add class.get_dependencies() callback Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 08/13] gpio: sysfs: implement class.get_dependencies() Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 17:40 ` Mark Brown 2015-06-17 17:40 ` Mark Brown 2015-06-30 15:00 ` Tomeu Vizoso 2015-06-30 15:00 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 09/13] gpu: host1x: " Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 10/13] driver-core: add for_each_class() Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 11/13] device property: add fwnode_get_parent() Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 12/13] device property: add fwnode_get_name() Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 13:42 ` [PATCH 13/13] driver-core: probe dependencies before probing Tomeu Vizoso 2015-06-17 13:42 ` Tomeu Vizoso 2015-06-17 18:13 ` Mark Brown 2015-06-17 18:13 ` Mark Brown 2015-06-30 15:18 ` Tomeu Vizoso 2015-06-30 15:18 ` Tomeu Vizoso 2015-06-18 9:42 ` [PATCH 00/13] Discover and probe dependencies Andrzej Hajda 2015-06-18 9:42 ` Andrzej Hajda 2015-06-18 9:57 ` Russell King - ARM Linux 2015-06-18 9:57 ` Russell King - ARM Linux 2015-06-18 10:36 ` Mark Brown 2015-06-18 10:36 ` Mark Brown 2015-06-18 13:14 ` Andrzej Hajda 2015-06-18 13:14 ` Andrzej Hajda 2015-06-18 14:38 ` Tomeu Vizoso 2015-06-18 14:38 ` Tomeu Vizoso 2015-06-18 14:49 ` Russell King - ARM Linux 2015-06-18 14:49 ` Russell King - ARM Linux 2015-06-18 15:32 ` Alexander Holler 2015-06-18 15:32 ` Alexander Holler 2015-06-18 14:57 ` Tomeu Vizoso 2015-06-18 14:57 ` Tomeu Vizoso
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=1513496.zoUTpU2Ou0@vostro.rjw.lan \ --to=rjw@rjwysocki.net \ --cc=a.hajda@samsung.com \ --cc=arnd@arndb.de \ --cc=broonie@kernel.org \ --cc=dmitry.torokhov@gmail.com \ --cc=galak@codeaurora.org \ --cc=gnurou@gmail.com \ --cc=grant.likely@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=holler@ahsoftware.de \ --cc=ijc+devicetree@hellion.org.uk \ --cc=javier.martinez@collabora.co.uk \ --cc=k.kozlowski@samsung.com \ --cc=lenb@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=lv.zheng@intel.com \ --cc=mark.rutland@arm.com \ --cc=pawel.moll@arm.com \ --cc=robert.moore@intel.com \ --cc=robh+dt@kernel.org \ --cc=robherring2@gmail.com \ --cc=swarren@wwwdotorg.org \ --cc=tbergstrom@nvidia.com \ --cc=thierry.reding@gmail.com \ --cc=tomeu.vizoso@collabora.com \ /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.