From: Matthias Kaehlcke <mka@chromium.org>
To: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Brian Norris <briannorris@chromium.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org,
Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH] regulator: core: Limit propagation of parent voltage count and list
Date: Mon, 27 Mar 2017 11:20:40 -0700 [thread overview]
Message-ID: <20170327182040.GC84219@google.com> (raw)
In-Reply-To: <b7929693-fbb0-f5ce-da44-6c378cc25e0d@osg.samsung.com>
El Mon, Mar 27, 2017 at 01:54:50PM -0400 Javier Martinez Canillas ha dit:
> On 03/27/2017 01:39 PM, Matthias Kaehlcke wrote:
>
> >>>> + if (ops->get_voltage || ops->get_voltage_sel)
> >>
> >> It's valid to have a .get_voltage_sel callback without a .list_voltage?
> >>
> >> At least it seems that _regulator_get_voltage() assumes that having a
> >> .get_voltage_sel implies that a .list_voltage will also be available.
> >>
> >> static int _regulator_get_voltage(struct regulator_dev *rdev)
> >> {
> >> ...
> >> if (rdev->desc->ops->get_voltage_sel) {
> >> sel = rdev->desc->ops->get_voltage_sel(rdev);
> >> if (sel < 0)
> >> return sel;
> >> ret = rdev->desc->ops->list_voltage(rdev, sel);
> >> } else if (rdev->desc->ops->get_voltage) {
> >> ...
> >> }
> >
> > The same function (from which I derived the conditions) suggests that
> > a regulator could have a .list_voltage op even if it doesn't have
> > .get_voltage_sel:
> >
> >> ...
> >> if (rdev->desc->ops->get_voltage_sel) {
> >> ...
> >> } else if (rdev->desc->ops->get_voltage) {
> >> ...
> >> } else if (rdev->desc->ops->list_voltage) {
> >
> > I don't know for sure if this condition is superfluous or if there are
> > cases where it makes sense to have a .list_voltage but not
> > .get_voltage_sel.
> >
>
> I don't think is the same condition. Unless I'm misreading the code
> what it's checking is if there's a .list_voltage even when there is
> no .get_voltage_sel.
>
> IOW, it's valid to have a .list_voltage even when there's no callback
> for .get_voltage_sel, but the opposite isn't true.
I see, thanks for the clarification.
> >> I wonder if instead of always checking if the regulator lacks operations,
> >> it wouldn't be better to do it just once and store that the regulator is
> >> a switch so that state can be used as explicit check for switch instead.
> >>
> >> Something like if (!rdev->supply || !rdev->switch) looks more clear
> >> to me.
> >
> > I agree and we can even reduce it to if (!rdev_switch) since a switch
> > implicitly has a supply.
> >
>
> I wonder if that's always true. What happens if you have a switch but
> its <name>-supply parent isn't defined in the Device Tree?
My idea was to only set rdev->switch after having resolved the
parent supply, though I concede this is not semantically. Maybe we
still want this logic but give the flag a different name?
Matthias
prev parent reply other threads:[~2017-03-27 18:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 20:09 [PATCH] regulator: core: Limit propagation of parent voltage count and list Matthias Kaehlcke
2017-03-24 20:38 ` Brian Norris
2017-03-25 5:05 ` Javier Martinez Canillas
2017-03-27 10:21 ` Mark Brown
2017-03-27 17:39 ` Matthias Kaehlcke
2017-03-27 17:54 ` Javier Martinez Canillas
2017-03-27 18:13 ` Mark Brown
2017-03-27 18:20 ` Matthias Kaehlcke [this message]
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=20170327182040.GC84219@google.com \
--to=mka@chromium.org \
--cc=briannorris@chromium.org \
--cc=broonie@kernel.org \
--cc=dianders@chromium.org \
--cc=javier@osg.samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@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.