From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Michael Williamson <michael.williamson@criticallink.com>
Cc: linux-kernel@vger.kernel.org, lrg@slimlogic.co.uk,
broonie@opensource.wolfsonmicro.com, gregkh@suse.de
Subject: Re: [PATCH RESEND] tps65023: Allow platforms to specify DCDC_2 and DCDC_3 value.
Date: Sat, 4 Sep 2010 10:37:23 -0700 [thread overview]
Message-ID: <20100904173723.GB10918@core.coreip.homeip.net> (raw)
In-Reply-To: <4C827E16.9090409@criticallink.com>
On Sat, Sep 04, 2010 at 01:12:54PM -0400, Michael Williamson wrote:
> Hello Dmitry,
>
> On 09/04/2010 01:01 PM, Dmitry Torokhov wrote:
> > Hi Michael,
> >
> > On Sat, Sep 04, 2010 at 12:04:31PM -0400, Michael Williamson wrote:
> >> The TPS65023 regulator includes 5 regulators (3 DCDC and 2 LDO's).
> >> 2 of the DCDC regulators are of fixed voltage and can only be
> >> turned on or off via the I2C interface. The current driver defaults
> >> the values of the fixed DCDC regulators. However, the actual
> >> voltage of these regulators may be set differently for a board (via
> >> voltage divider circuit, etc.).
> >>
> >> This patch allows a platform to pass in the actual voltage used
> >> for these DCDC supplies such that they are reported correctly in
> >> sysfs.
> >>
> >> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
> >> ---
> >> Previous submission said 1/3. Should only be 1/1.
> >>
> >> drivers/regulator/tps65023-regulator.c | 17 +++++++++++++----
> >> 1 files changed, 13 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/regulator/tps65023-regulator.c b/drivers/regulator/tps65023-regulator.c
> >> index cd6d4fc..68cd7d3 100644
> >> --- a/drivers/regulator/tps65023-regulator.c
> >> +++ b/drivers/regulator/tps65023-regulator.c
> >> @@ -124,7 +124,7 @@ struct tps_pmic {
> >> struct regulator_desc desc[TPS65023_NUM_REGULATOR];
> >> struct i2c_client *client;
> >> struct regulator_dev *rdev[TPS65023_NUM_REGULATOR];
> >> - const struct tps_info *info[TPS65023_NUM_REGULATOR];
> >> + struct tps_info *info[TPS65023_NUM_REGULATOR];
> >> struct mutex io_lock;
> >> };
> >>
> >> @@ -462,9 +462,10 @@ static int __devinit tps_65023_probe(struct i2c_client *client,
> >> const struct i2c_device_id *id)
> >> {
> >> static int desc_id;
> >> - const struct tps_info *info = (void *)id->driver_data;
> >> + struct tps_info *info = (void *)id->driver_data;
> >
> > id is shared between multiple instances of the device and is constant.
> > It is a bad idea to cast away constness and modify the data; you should
> > move data that may be adjusted into tps_pmic structure.
> >
> > Even if we expect to only a single instance of the device in question we
> > should follow best practices.
> >
> Yes of course. Hadn't thought of multiple instances. I will correct and resubmit.
> Thank you.
>
> >> struct regulator_init_data *init_data;
> >
> > This should probably be marked const too as it comes from platform code.
> >
> >> struct regulator_dev *rdev;
> >> + struct regulation_constraints *c;
> >
> > const as well?
> >
> Right.
>
> >> struct tps_pmic *tps;
> >> int i;
> >> int error;
> >> @@ -501,6 +502,14 @@ static int __devinit tps_65023_probe(struct i2c_client *client,
> >> tps->desc[i].type = REGULATOR_VOLTAGE;
> >> tps->desc[i].owner = THIS_MODULE;
> >>
> >> + /* Override default DCDC2/3 values if provided */
> >> + c = &init_data->constraints;
> >> + if ((i == TPS65023_DCDC_2) || (i == TPS65023_DCDC_3)
> >> + && c->min_uV && c->min_uV == c->max_uV) {
> >
> > Min and max are the same? You sure you got the condition right?
> >
> These DCDC regulators are fixed in hardware, they cannot be controlled and should
> only have one value (minus hardware tolerance, I suppose). I thought that such a
> sanity check would be required. What should the reported value be if a range is
> provided?
>
Ah, I see. If there was a comment it would be clearer though (I see it
described in the commit log but I think this is one of cases when
comment in the code might be useful too).
BTW, what if board code simply wants to reduce the range, for one reason
or another? Maybe c->min_uV <= c->max_uV would be a better sanity check?
--
Dmitry
prev parent reply other threads:[~2010-09-04 17:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-04 16:04 Michael Williamson
2010-09-04 17:01 ` Dmitry Torokhov
2010-09-04 17:12 ` Michael Williamson
2010-09-04 17:37 ` Dmitry Torokhov [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=20100904173723.GB10918@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=michael.williamson@criticallink.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
all inboxes | Powered by JetHome®