Re: [PATCH 00/21] On-demand device registration

[Tomeu Vizoso <tomeu.vizoso@collabora.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
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel