From: tomeu.vizoso@collabora•com (Tomeu Vizoso)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 00/21] On-demand device registration
Date: Thu, 11 Jun 2015 11:56:26 +0200 [thread overview]
Message-ID: <55795B4A.6030008@collabora.com> (raw)
In-Reply-To: <CACRpkdYyvXVm=UBVH9Lwp8nQbuxQL07MLspNfQSHtc-yT2C_0g@mail.gmail.com>
On 06/11/2015 10:15 AM, Linus Walleij wrote:
> On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
> <tomeu.vizoso@collabora•com> wrote:
>> On 10 June 2015 at 09:30, Linus Walleij <linus.walleij@linaro•org> wrote:
>
>>> regulator_get(...) -> not available, so:
>>> - identify target regulator provider - this will need instrumentation
>>> - probe it
>>>
>>> It then turns out the regulator driver is on the i2c bus, so we
>>> need to probe the i2c driver:
>>> - identify target i2c host for the regulator driver - this will need
>>> instrumentation
>>> - probe the i2c host driver
>>>
>>> i2c host comes out, probes the regulator driver, regulator driver
>>> probes and then the regulator_get() call returns.
>>
>> Hmm, if I understand correctly what you say, this is exactly what this
>> particular series does:
>>
>> regulator_get -> of_platform_device_ensure -> probe() on the platform
>> device that encloses the requested device node (i2c host) -> i2c slave
>> gets probed and the regulator registered -> regulator_get returns the
>> requested resource
>
> Yes. But only for device tree.
>
>> The downside I'm currently looking at is that an explicit dependency
>> graph would be useful to have for other purposes. For example to print
>> a neat warning when a dependency cannot be fulfilled. Or to refuse to
>> unbind a device which other devices depend on, or to automatically
>> unbind the devices that depend on it, or to print a warning if a
>> device is hotplugged off and other devices depend on it.
>
> Unbind/remove() calls are the inverse usually yes.
>
> But also the [runtime] power up/down sequences for the
> devices tend to depend on a similar ordering or mostly
> the same. (Mentioned this before I think.)
>
>>> This requires instrumentation on anything providing a resource
>>> to another driver like those I mentioned and a lot of overhead
>>> infrastructure, but I think it's the right approach. However I don't
>>> know if I would ever be able to pull that off myself, I know talk
>>> is cheap and I should show the code instead.
>>
>> Yeah, if you can give it a second look and say if it matches what you
>> wrote above, it would be very much appreciated.
>
> Yes you are right. But what about ACPI, board files,
> Simple Firmware and future hardware description languages...
Ah ok, got it now. With fwnode and by moving a bit of code around that
shouldn't be a problem.
I'm actually now implementing the alternative approach in which
dependencies are discovered before the device is probed, then probed in
turn until all are available. So functionally is very similar but I
expect to find big differences in how the codebase is impacted.
Regards,
Tomeu
> Yours,
> Linus Walleij
>
next prev parent reply other threads:[~2015-06-11 9:56 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-25 14:53 [PATCH 00/21] On-demand device registration Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 01/21] regulator: core: Reduce critical area in _regulator_get Tomeu Vizoso
2015-05-25 17:18 ` Mark Brown
2015-05-25 17:45 ` Mark Brown
2015-05-25 14:53 ` [PATCH 02/21] ARM: tegra: Add gpio-ranges property Tomeu Vizoso
2015-05-26 19:41 ` Stephen Warren
2015-05-27 14:18 ` Tomeu Vizoso
2015-05-27 14:49 ` Stephen Warren
2015-05-28 8:26 ` Tomeu Vizoso
2015-05-28 15:50 ` Stephen Warren
2015-06-16 7:53 ` Tomeu Vizoso
2015-06-02 11:28 ` Linus Walleij
2015-06-02 15:40 ` Stephen Warren
2015-06-16 8:42 ` Tomeu Vizoso
2015-06-16 20:32 ` Stephen Warren
2015-06-17 10:04 ` Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 03/21] ARM: tegra: Register drivers before devices Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 04/21] ARM: EXYNOS: " Tomeu Vizoso
2015-05-26 0:41 ` Krzysztof Kozlowski
2015-05-25 14:53 ` [PATCH 05/21] ARM i.MX6q: " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 06/21] of/platform: Add of_platform_device_ensure() Tomeu Vizoso
2015-05-26 18:56 ` Dmitry Torokhov
2015-05-27 8:04 ` Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 07/21] of/platform: Ensure device registration on lookup Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 08/21] gpio: Probe GPIO drivers on demand Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 09/21] gpio: Probe pinctrl devices " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 10/21] regulator: core: Probe regulators " Tomeu Vizoso
2015-05-25 17:32 ` Mark Brown
2015-05-26 6:17 ` Tomeu Vizoso
2015-05-26 9:36 ` Mark Brown
2015-05-26 15:08 ` Tomeu Vizoso
2015-05-26 16:54 ` Mark Brown
2015-05-26 17:53 ` Tomeu Vizoso
2015-05-26 19:55 ` Mark Brown
2015-05-25 14:53 ` [PATCH 11/21] drm: Probe panels " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 12/21] drm/tegra: Probe dpaux devices " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 13/21] i2c: core: Probe i2c master " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 14/21] pwm: Probe PWM chip " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 15/21] backlight: Probe backlight " Tomeu Vizoso
2015-05-26 7:18 ` Lee Jones
2015-05-26 7:25 ` Sascha Hauer
2015-05-26 8:39 ` Lee Jones
2015-05-26 12:01 ` Tomeu Vizoso
2015-05-26 13:34 ` Lee Jones
2015-05-25 14:53 ` [PATCH 16/21] usb: phy: Probe phy " Tomeu Vizoso
2015-05-26 14:44 ` Felipe Balbi
2015-05-25 14:53 ` [PATCH 17/21] clk: Probe clk providers " Tomeu Vizoso
2015-05-28 6:16 ` Michael Turquette
2015-05-25 14:53 ` [PATCH 18/21] pinctrl: Probe pinctrl devices " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 19/21] phy: core: Probe phy providers " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 20/21] dma: of: Probe DMA controllers " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 21/21] power-supply: Probe power supplies " Tomeu Vizoso
2015-05-28 4:33 ` [PATCH 00/21] On-demand device registration Rob Herring
2015-06-03 19:57 ` Grygorii.Strashko@linaro•org
2015-06-04 8:39 ` Tomeu Vizoso
2015-06-04 16:51 ` Grygorii.Strashko@linaro•org
2015-06-04 20:39 ` Alexander Holler
2015-06-08 12:26 ` Enrico Weigelt, metux IT consult
2015-06-08 18:14 ` Alexander Holler
2015-06-08 18:18 ` Alexander Holler
2015-06-22 15:23 ` Tomeu Vizoso
2015-06-23 0:01 ` Rob Herring
2015-06-02 8:48 ` Linus Walleij
2015-06-02 10:14 ` Tomeu Vizoso
2015-06-10 7:30 ` Linus Walleij
2015-06-10 10:19 ` Tomeu Vizoso
2015-06-11 8:15 ` Linus Walleij
2015-06-11 9:56 ` Tomeu Vizoso [this message]
2015-06-03 21:12 ` Rob Clark
2015-06-04 21:03 ` Alexander Holler
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=55795B4A.6030008@collabora.com \
--to=tomeu.vizoso@collabora$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox