[PATCH 00/21] On-demand device registration

Linus Walleij linus.walleij at linaro.org
Thu Jun 11 01:15:04 PDT 2015

On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso
<tomeu.vizoso at collabora.com> wrote:
> On 10 June 2015 at 09:30, Linus Walleij <linus.walleij at 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...

Linus Walleij

More information about the dri-devel mailing list