All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Gregor Boirie <gregor.boirie@parrot.com>,
	Mark Brown <broonie@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Richard Leitner <dev@g0hl1n.net>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Gwendal Grignou <gwendal@chromium.org>
Subject: Re: [PATCH 1/5] iio: magn: ak8975: fix regulator usage
Date: Wed, 22 Jun 2016 17:41:51 +0200	[thread overview]
Message-ID: <CACRpkdZT_9gs9vPYGku2XeZnxaXPaE=X3XLWccPkB2iK9_KvcA@mail.gmail.com> (raw)
In-Reply-To: <576A7C28.70905@parrot.com>

Disclaimer: I am not the regulator maintainer but I think I
understand how these things are supposed to work.
Mark will correct me if I say something stupid, I hope.

On Wed, Jun 22, 2016 at 1:53 PM, Gregor Boirie <gregor.boirie@parrot.com> wrote:
> On 06/22/2016 12:18 AM, Linus Walleij wrote:

>>         data->vdd = devm_regulator_get(&client->dev, "vdd");
>> -       if (IS_ERR_OR_NULL(data->vdd)) {
>> +       if (IS_ERR(data->vdd)) {
>>                 ret = PTR_ERR(data->vdd);
>> -               if (ret == -ENODEV)
>> -                       ret = 0;
>
> what if dummy supplies are not allowed and regulator is not declared / found
> into device tree ?

What do you mean with "dummy supplies not allowed"? It is an
integral part of the regulator framework. It's not like you can choose
not to have it.

The only way a regulator doesn't resolve to a dummy
is with regulator_get_exclusive() which I'm not using or if your board
is lacking full constraints. (All DT boards have full constraints.)

In that case I think you should make sure to call
regulator_has_full_constraints() in your boardfile, and fix your
regulators because they're likely just broken.

> I have no such regulator on some boards, just a main power supply that is
> not driven by soft.

That should be defined in the DT as a fixed regulator
something like this:

+               /* Main power of the board: 3.7V */
+               vph: regulator-fixed {
+                       compatible = "regulator-fixed";
+                       regulator-min-microvolt = <3700000>;
+                       regulator-max-microvolt = <3700000>;
+                       regulator-name = "VPH";
+                       regulator-type = "voltage";
+                       regulator-always-on;
+                       regulator-boot-on;
+               };

This can also be done with a boardfile.

Of course also select REGULATOR_FIXED_VOLTAGE for
your board in KConfig.

> How should this be handled in this case ?

If the component has a (non-optional) external power
supply, its driver should issue regulator_get/enable for it.

If a board does not have all the proper regulators defined (which
is easy, in worst case just use fixed-regulator), it should
resort to use dummy regulators. It needs to call
regulator_has_full_constraints() for the dummies to kick in.

It is not proper to try to quirk around in the driver and
avoid getting a regulator just to stay compatible. Not
properly supplying either proper regulators nor dummies is
considered a bug.

Yours,
Linus Walleij

  reply	other threads:[~2016-06-22 15:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21 22:18 [PATCH 0/5] fix regulators and PM for AK8975 Linus Walleij
2016-06-21 22:18 ` [PATCH 1/5] iio: magn: ak8975: fix regulator usage Linus Walleij
2016-06-22 11:53   ` Gregor Boirie
2016-06-22 15:41     ` Linus Walleij [this message]
2016-06-23 10:48       ` Mark Brown
2016-06-21 22:18 ` [PATCH 2/5] iio: magn: ak8975: add Vid regulator Linus Walleij
2016-06-21 22:18 ` [PATCH 3/5] iio: magn: ak8975: refactor regulator handlers Linus Walleij
2016-06-21 22:18 ` [PATCH 4/5] iio: magn: ak8975: allow a delay after enabling regulators Linus Walleij
2016-06-21 22:18 ` [PATCH 5/5] iio: magn: ak8975: deploy runtime PM Linus Walleij
2016-06-22  9:26   ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACRpkdZT_9gs9vPYGku2XeZnxaXPaE=X3XLWccPkB2iK9_KvcA@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=broonie@kernel.org \
    --cc=dev@g0hl1n.net \
    --cc=gregor.boirie@parrot.com \
    --cc=gwendal@chromium.org \
    --cc=jic23@kernel.org \
    --cc=k.kozlowski@samsung.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.