From: Mark Brown <broonie@kernel.org>
To: Tim Kryger <tim.kryger@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] regulator: Allow set voltage on fixed regulators
Date: Fri, 18 Apr 2014 22:29:31 +0100 [thread overview]
Message-ID: <20140418212931.GB12304@sirena.org.uk> (raw)
In-Reply-To: <CAAYSxhoXvpxphks9p2Y8f0yUUp-4PeOjd2JiSYpsd_qvrRh6vA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]
On Fri, Apr 18, 2014 at 02:07:58PM -0700, Tim Kryger wrote:
> On Fri, Apr 18, 2014 at 11:52 AM, Mark Brown <broonie@kernel.org> wrote:
> > This seems like the wrong place to fix this, it's nothing to do with DT
> > and we shouldn't require that nonsensical permissions are set. Instead
> > we should fix this at the point where we're implementing the permission
> > check, have the failure case check the current voltage before returning
> > an error.
> Are you saying that REGULATOR_CHANGE_VOLTAGE and
> REGULATOR_CHANGE_CURRENT are nonsense?
Flagging that it's possible to change the voltage of a fixed voltage
regulator is nonsense.
> It does seem like, even in the non-DT case, that the decision of
> whether to call the underlying set_voltage and set_current functions
> could be made solely based on the numerical voltage and current
> constraints.
The reason they're split is to encourage people to put the information
about what's supposed to work in there - you might know what the valid
range is but also know that the drivers are buggy and will break if they
try to actually vary the voltage. But yes, in general you should never
have a range without the ability to use it once everything is working
properly so having one without the other at least indicates that things
aren't complete in the non-DT case.
It does also make the contract a bit clearer, one of the concerns
initially was that we wanted to be absolutely clear that the
machine integration was responsible for enabling the ability to change
things in case people broke boards.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-04-18 21:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-18 18:30 Tim Kryger
2014-04-18 18:52 ` Mark Brown
2014-04-18 21:07 ` Tim Kryger
2014-04-18 21:29 ` Mark Brown [this message]
2014-04-22 18:38 ` Tim Kryger
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=20140418212931.GB12304@sirena.org.uk \
--to=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tim.kryger@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®