From: Tomeu Vizoso <tomeu.vizoso@collabora.com> To: Andrzej Hajda <a.hajda@samsung.com> Cc: "Mark Brown" <broonie@kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "Alexander Holler" <holler@ahsoftware.de>, "Alexandre Courbot" <gnurou@gmail.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 Rutland" <mark.rutland@arm.com>, "Pawel Moll" <pawel.moll@arm.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, "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 00/13] Discover and probe dependencies Date: Thu, 18 Jun 2015 16:38:59 +0200 [thread overview] Message-ID: <CAAObsKAERGvt=tECODWmUTrJOhxi_RpCfZ1d6h83vrgPMOxmEQ@mail.gmail.com> (raw) In-Reply-To: <5582C437.4030108@samsung.com> On 18 June 2015 at 15:14, Andrzej Hajda <a.hajda@samsung.com> wrote: > On 06/18/2015 12:36 PM, Mark Brown wrote: >> On Thu, Jun 18, 2015 at 11:42:01AM +0200, Andrzej Hajda wrote: >> >> There's something really messed up with how your mailer is word wrapping >> paragraphs, might want to check it out - it looks like it's making lines >> that are longer than 80 columns and then randomly breaking them 80 >> columns in rather than reflowing things. >> >>> 3. Dependencies are mandatory, ie without it driver will not be able to >>> successfully finish >>> the probe. >>> It should be not true. Sometimes device will require given resource >>> only in specific >>> scenario, or it can still probe successfully and ask for the >>> resource later. >>> I can also imagine that firmware can describe more information than >>> given driver require, >>> some resources even if they are present in the dts, will be not >>> requested by the driver, it >>> can be the case of drivers providing limited functionality, or just >>> obsolete bindings. >> Well, this isn't clear - the model here seems to be that the >> dependencies are those that are explicitly listed for a given platform. >> For those our current expectation is that we will try to control them >> and will defer probe until the resources that are mapped in on the >> platform are present so this doesn't seem like a change. > IMO current assumption is that we CAN TRY to control them > and we MAY defer probe until resource is present, nothing mandatory. > > Lets look at more real example: we have HDMI encoder which can > use some video and audio resources provided by some video and audio > drivers. If we know that our machine will work without sound we can > disable audio drivers but we can expect video should still work, ie HDMI > driver should successfully probe even if audio resources are not available. > > I had an impression that in this patchset the device wont be probed > until all dependencies are present, but after looking at the code it > does not seems to be true - in case dependency cannot be probed > warning will be printed but the probe will continue, so it should handle > scenario above properly. Yeah, I think deferred probe is a very good way to make sure that we get a working system at the end. It's just that as we probe devices in a random order, we'd get a lot of noise if we printed something every time a device failed to find a resource and deferred its probe. You can see these series as just changing the order in which we probe devices, to one in which dependencies are probed before the device that depends on them. > The only minor issue is that we will see > sometimes misleading message about missing dependencies. Yes, that's why they are currently pr_debug and not pr_warn. I think that once we have tables specifying the resources needed by each driver (ala devm_probe), we can know which are optional and print appropriate warnings accordingly. Thanks, Tomeu > Regards > Andrzej > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
WARNING: multiple messages have this Message-ID (diff)
From: tomeu.vizoso@collabora.com (Tomeu Vizoso) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 00/13] Discover and probe dependencies Date: Thu, 18 Jun 2015 16:38:59 +0200 [thread overview] Message-ID: <CAAObsKAERGvt=tECODWmUTrJOhxi_RpCfZ1d6h83vrgPMOxmEQ@mail.gmail.com> (raw) In-Reply-To: <5582C437.4030108@samsung.com> On 18 June 2015 at 15:14, Andrzej Hajda <a.hajda@samsung.com> wrote: > On 06/18/2015 12:36 PM, Mark Brown wrote: >> On Thu, Jun 18, 2015 at 11:42:01AM +0200, Andrzej Hajda wrote: >> >> There's something really messed up with how your mailer is word wrapping >> paragraphs, might want to check it out - it looks like it's making lines >> that are longer than 80 columns and then randomly breaking them 80 >> columns in rather than reflowing things. >> >>> 3. Dependencies are mandatory, ie without it driver will not be able to >>> successfully finish >>> the probe. >>> It should be not true. Sometimes device will require given resource >>> only in specific >>> scenario, or it can still probe successfully and ask for the >>> resource later. >>> I can also imagine that firmware can describe more information than >>> given driver require, >>> some resources even if they are present in the dts, will be not >>> requested by the driver, it >>> can be the case of drivers providing limited functionality, or just >>> obsolete bindings. >> Well, this isn't clear - the model here seems to be that the >> dependencies are those that are explicitly listed for a given platform. >> For those our current expectation is that we will try to control them >> and will defer probe until the resources that are mapped in on the >> platform are present so this doesn't seem like a change. > IMO current assumption is that we CAN TRY to control them > and we MAY defer probe until resource is present, nothing mandatory. > > Lets look at more real example: we have HDMI encoder which can > use some video and audio resources provided by some video and audio > drivers. If we know that our machine will work without sound we can > disable audio drivers but we can expect video should still work, ie HDMI > driver should successfully probe even if audio resources are not available. > > I had an impression that in this patchset the device wont be probed > until all dependencies are present, but after looking at the code it > does not seems to be true - in case dependency cannot be probed > warning will be printed but the probe will continue, so it should handle > scenario above properly. Yeah, I think deferred probe is a very good way to make sure that we get a working system at the end. It's just that as we probe devices in a random order, we'd get a lot of noise if we printed something every time a device failed to find a resource and deferred its probe. You can see these series as just changing the order in which we probe devices, to one in which dependencies are probed before the device that depends on them. > The only minor issue is that we will see > sometimes misleading message about missing dependencies. Yes, that's why they are currently pr_debug and not pr_warn. I think that once we have tables specifying the resources needed by each driver (ala devm_probe), we can know which are optional and print appropriate warnings accordingly. Thanks, Tomeu > Regards > Andrzej > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2015-06-18 14:39 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 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 [this message] 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='CAAObsKAERGvt=tECODWmUTrJOhxi_RpCfZ1d6h83vrgPMOxmEQ@mail.gmail.com' \ --to=tomeu.vizoso@collabora.com \ --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=rjw@rjwysocki.net \ --cc=robert.moore@intel.com \ --cc=robh+dt@kernel.org \ --cc=swarren@wwwdotorg.org \ --cc=tbergstrom@nvidia.com \ --cc=thierry.reding@gmail.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.