From: Liam Girdwood <lg@opensource.wolfsonmicro.com>
To: pHilipp Zabel <philipp.zabel@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
arm kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [PATCH 05/15] regulator: regulator framework core
Date: Thu, 10 Jul 2008 18:07:48 +0100 [thread overview]
Message-ID: <1215709668.13431.83.camel@odin> (raw)
In-Reply-To: <74d0deb30807100904o404be423s314cc206a963396c@mail.gmail.com>
On Thu, 2008-07-10 at 18:04 +0200, pHilipp Zabel wrote:
> On Thu, Jul 10, 2008 at 5:26 PM, Liam Girdwood
> <lg@opensource.wolfsonmicro.com> wrote:
> > +
> > +/* current constraint check */
> > +static int regulator_check_current_limit(struct regulator_dev *rdev,
> > + int *min_uA, int *max_uA)
> > +{
> > + BUG_ON(*min_uA > *max_uA);
> > +
> > + if (!rdev->constraints) {
> > + printk(KERN_ERR "%s: no constraints for %s\n", __func__,
> > + rdev->desc->name);
> > + return -ENODEV;
> > + }
> > + if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_CURRENT)) {
> > + printk(KERN_ERR "%s: operation not allowed for %s\n",
> > + __func__, rdev->desc->name);
> > + return -EPERM;
> > + }
> > +
> > + if (*max_uA > rdev->constraints->max_uA ||
> > + *min_uA < rdev->constraints->min_uA) {
> > + printk(KERN_ERR "%s: invalid current range %d-%duA for %s\n",
> > + __func__, *min_uA, *max_uA, rdev->desc->name);
> > + return -EINVAL;
> > + }
> > +
> > + *min_uA = max(*min_uA, rdev->constraints->min_uA);
> > + *max_uA = min(*max_uA, rdev->constraints->max_uA);
>
> I don't understand this part. If max_uA > constraints->max_uA or
> min_uA < constraints->min_uA, we returned with -EINVAL above. So in
> this place
> I'd expect min_uA to be >= constraints->min_uA and max_uA <=
> constraints->max_uA, in which case the last two statements are no-ops.
>
It looks like the limit check with printk was added post min()/max()
here and does indeed make them no-ops. I'll remove.
> In comparison, regulator_check_voltage silently fixes the requested
> voltage range to fit into the constraints. Should
> regulator_check_current_limit do the same?
Yes, current should do the same and make sure the our consumers
requested current window fits into the system constraints like voltage.
Atm it just rejects it.
Thanks
Liam
prev parent reply other threads:[~2008-07-10 17:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 15:26 Liam Girdwood
2008-07-10 16:04 ` pHilipp Zabel
2008-07-10 17:07 ` Liam Girdwood [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=1215709668.13431.83.camel@odin \
--to=lg@opensource.wolfsonmicro.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=philipp.zabel@gmail.com \
/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
Powered by JetHome