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

[Doug Anderson]

Stephen,

On Thu, Feb 14, 2013 at 3:35 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> [    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.

It's printed by "core.c" in drivers/regulator.

    pr_warn("%s supply %s not found, using dummy regulator\n",
             devname, id);
    rdev = dummy_regulator_rdev;
    goto found;

We can avoid that logic with has_full_constraints.  That will be some
work to get done but also should be done at some point in time.  Once
we use has_full_constraints we'll get ERR_PTR(-EPROBE_DEFER);

...but then we're SOL since the function callback that is setting this
regulator has this prototype:

    void (*set_power)(struct plat_lcd_data *, unsigned int power);

...notice a lack of an error return.  ...and actually a lack of pretty
much everything.  platform-lcd needs some lovin.


>> 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.

Fair enough; if deferring and hoping is the way that it's done then
I'll need to live with it.

...since there are a lot of yaks to shave to actually get
-EPROBE_DEFER to work (fix so that has_full_constraints works and also
fix so that platform-lcd can handle failure of lcd_set_power), I'm
still planning to send up the patch with subsys_initcall as soon as I
can.

I have filed a bug in the Chromium OS tracker to track at least the
issues with platform-lcd: http://crosbug.com/38971


-Doug