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

On 02/14/2013 02:40 PM, Doug Anderson wrote:

On Wed, Feb 13, 2013 at 4:54 PM, Doug Anderson [off-list ref] wrote:

quoted

quoted

quoted

quoted

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.