On Tue, Oct 22, 2019 at 6:00 PM Bartosz Golaszewski
<bgolaszewski@xxxxxxxxxxxx> wrote:
>
> wt., 22 paź 2019 o 09:27 Tomasz Figa <tfiga@xxxxxxxxxxxx> napisał(a):
> >
> > On Tue, Oct 22, 2019 at 1:53 AM Bartosz Golaszewski
> > <bgolaszewski@xxxxxxxxxxxx> wrote:
> > >
> > > pt., 18 paź 2019 o 10:26 Bibby Hsieh <bibby.hsieh@xxxxxxxxxxxx> napisał(a):
> > > >
> > > > Although in the most platforms, the power of eeprom and i2c
> > > > are alway on, some platforms disable the eeprom and i2c power
> > > > in order to meet low power request.
> > > > This patch add the pm_runtime ops to control power to support
> > > > all platforms.
> > > >
> > > > Changes since v3:
> > > > - remove redundant calling function
> > > > - change SIMPLE_DEV_PM_OPS to SET_RUNTIME_PM_OPS
> > > > - change supply name
> > > >
> > > > Changes since v2:
> > > > - rebase onto v5.4-rc1
> > > > - pm_runtime_disable and regulator_bulk_disable at
> > > > err return in probe function
> > > >
> > > > Changes since v1:
> > > > - remove redundant code
> > > > - fixup coding style
> > > >
> > > > Signed-off-by: Bibby Hsieh <bibby.hsieh@xxxxxxxxxxxx>
> > > > ---
> > > > drivers/misc/eeprom/at24.c | 64 ++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 64 insertions(+)
> > > >
> > > > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> > > > index 2cccd82a3106..68ced4f25916 100644
> > > > --- a/drivers/misc/eeprom/at24.c
> > > > +++ b/drivers/misc/eeprom/at24.c
> > > > @@ -22,6 +22,7 @@
> > > > #include <linux/nvmem-provider.h>
> > > > #include <linux/regmap.h>
> > > > #include <linux/pm_runtime.h>
> > > > +#include <linux/regulator/consumer.h>
> > > > #include <linux/gpio/consumer.h>
> > > >
> > > > /* Address pointer is 16 bit. */
> > > > @@ -67,6 +68,12 @@
> > > > * which won't work on pure SMBus systems.
> > > > */
> > > >
> > > > +static const char * const at24_supply_names[] = {
> > > > + "vcc", "i2c",
> > > > +};
> > > > +
> > > > +#define AT24_NUM_SUPPLIES ARRAY_SIZE(at24_supply_names)
> > > > +
> > > > struct at24_client {
> > > > struct i2c_client *client;
> > > > struct regmap *regmap;
> > > > @@ -91,6 +98,8 @@ struct at24_data {
> > > >
> > > > struct gpio_desc *wp_gpio;
> > > >
> > > > + bool has_supplies;
> > > > + struct regulator_bulk_data supplies[AT24_NUM_SUPPLIES];
> > > > /*
> > > > * Some chips tie up multiple I2C addresses; dummy devices reserve
> > > > * them for us, and we'll use them with SMBus calls.
> > > > @@ -662,6 +671,17 @@ static int at24_probe(struct i2c_client *client)
> > > > at24->client[0].client = client;
> > > > at24->client[0].regmap = regmap;
> > > >
> > > > + regulator_bulk_set_supply_names(at24->supplies,
> > > > + at24_supply_names, AT24_NUM_SUPPLIES);
> > > > + err = devm_regulator_bulk_get(&at24->client[0].client->dev,
> > > > + AT24_NUM_SUPPLIES, at24->supplies);
> > > > + if (err == -ENODEV)
> > > > + at24->has_supplies = NULL;
> > >
> > > I just gave this a spin and noticed that this will never happen - the
> > > regulator core will use a dummy regulator if none is defined in DT.
> > > The only way for this to make sense would be to use
> > > regulator_get_optional() for each supply separately. But actually I
> > > think we should just leave it this way and remove this if. In the end:
> > > this chip needs some power supply, so dummy regulator makes sense.
> >
> > Thanks for testing. I'd still like to make sure what happens on non-DT
> > platforms.
> >
> > I can see that the core returns the dummy regulator if
> > have_full_constraints() [1]. That is always true for DT systems, but
> > for others it's false by default, unless someone explicitly calls
> > regulator_has_full_constraints() [2].
> >
>
> Not tested yet, but from the code it looks like it will then keep
> returning EPROBE_DEFER which doesn't sound right really, especially
> since we're printing an error message too. Shouldn't it be -ENODEV?
That's an interesting finding. Liam, Mark, what's the proper way to
bulk get optional regulators?
Best regards,
Tomasz
>
> Bart
>
> > [1] https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/regulator/core.c#L1787
> > [2] https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/regulator/core.c#L120
> >
> > Best regards,
> > Tomasz
