Re: [PATCH v1 1/4] i2c: mux: Add i2c-arbitrator 'mux' driver

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 02/14/2013 02:40 PM, Doug Anderson wrote:
> On Wed, Feb 13, 2013 at 4:54 PM, Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>>>> You should be able to replace all that with:
>>>>>
>>>>> module_platform_driver(&i2c_arbitrator_driver);
...
> OK, so I dug into my problems here a little bit.  All of the problems
> are with a private branch that includes stuff not fully upstream,
> but...
> 
> The problem is that we've got a regulator (tps65090) on this bus.
> Right now the first code that wants to use tps65090 runs from the
> set_power() callback of "platform-lcd".  It looks like:
>    lcd_fet = regulator_get(NULL, "lcd_vdd");
> 
> ...and "platform-lcd" is instantiated really early via
> platform_device_register() for some reason.
> 
> I tried to fix it by moving platform-lcd to actually be instantiated
> via the device tree (with platform data populated through
> of_platform_populate).  I then hooked up regulators through the device
> tree:

It shouldn't matter when the platform-lcd device is instantiated, so
doing it via a board file vs. a device tree shouldn't make much difference.

...
> ...but when I moved to module_platform_driver() then things still broke.
> 
> [    1.510000] platform-lcd supply lcd_vdd not found, using dummy regulator

What prints that? I assume that's some error-handling logic in the
platform-lcd driver. It's probably not detecting an -EPROBE_DEFFERED
return from regulator_get() correctly, and hence proceeding with the
probe() when it should simply return and let the kernel retry the
probe() later.

> I was sorta hoping that there would be some magic where
> regulator_get() would find the device tree node for the regulator and
> then resolve the chain.  ...but maybe that's a pipe dream.

regulator_get() won't forcibly probe() the whole dependency chain. The
idea is that if a driver tries to get a resource, and it fails with
-EPROBE_DEFER, the requesting driver should fail its own probe() with
that same error code, and the driver core will retry the failed probe()
later when the resource is hopefully available.

> Is there some better way I should be expressing dependencies?  Do I
> need to try to hack something together with -EAGAIN (ick!)?

Yes, basically. -EPROBE_DEFER specifically, although that might be an
alias for -EGAIN; I can't remember which way that went.