From: Robin Gong <b38343@freescale.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, grant.likely@linaro.org,
rob.herring@calxeda.com, lgirdwood@gmail.com,
shawn.guo@linaro.org, devicetree-discuss@lists.ozlabs.org,
linux-doc@vger.kernel.org, rob@landley.net
Subject: Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
Date: Sat, 13 Jul 2013 00:15:12 +0800 [thread overview]
Message-ID: <20130712161511.GA21203@Robin-OptiPlex-780> (raw)
In-Reply-To: <20130712144037.GJ24508@sirena.org.uk>
Mark,
Thanks for your kindly review, please see below comments.
On Fri, Jul 12, 2013 at 03:40:37PM +0100, Mark Brown wrote:
> On Fri, Jul 12, 2013 at 12:54:15PM +0800, Robin Gong wrote:
> > Add pfuze100 regulator driver.
>
> This looks mostly good. A few small issues below but nothing major.
>
> > +enum pfuze_id {
> > + PFUZE_ID_PFUZE100,
> > + PFUZE_ID_INVALID,
> > +};
> > +struct pfuze_chip {
>
> Missing blank line here - there are a few other small coding style
> things, checkpatch should help.
>
Thanks Mark, I will check carefully, although I have run the script...
> > +static struct regulator_ops pfuze100_ldo_regulator_ops;
> > +static struct regulator_ops pfuze100_fixed_regulator_ops;
> > +static struct regulator_ops pfuze100_sw_regulator_ops;
> > +static struct regulator_ops pfuze100_swb_regulator_ops;
>
> Better to just reorder things so that no forward declaration is needed.
>
Accept.
> > +static const int pfuze100_swbst[] = {
> > + 5000000, 5050000, 5100000, 5150000,
> > +};
>
> This looks like a linear map, the steps are all 50mV?
>
Yes, but the swbst regulator share the same define type with the vsnvs regulator, and the later voltage table is not linear, so I use volt_table in swbst regulator . I don't want to add another regulator type for this.
> > + num_regulators = pfuze_get_num_regulators_dt(&client->dev);
> > + if (num_regulators <= 0 && pdata)
> > + num_regulators = pdata->num_regulators;
> > + if (num_regulators <= 0) {
> > + dev_err(&client->dev, "no platform data,please add it!\n");
> > + ret = -EINVAL;
> > + return ret;
>
> You should just register all the regulators rather than only registering
> those that the user explicitly selects. This allows users to inpect the
> current configuration and simplifies the code - for example you don't
> need to count the DT nodes and you can just have a simple array in the
> platform data (see how wm831x does this for an example).
>
Yes, it will simplifies the code, but sometimes we will not use all the regulators on boards, in this case, Is it better that only register the available regulators?
> > + /* SW2~SW4 high bit check and modify the voltage value table */
> > + if (i > PFUZE100_SW1C && i < PFUZE100_SWBST) {
> > + regmap_read(pfuze_chip->regmap, PFUZE100_SW2VOL +
> > + (i - PFUZE100_SW2) * 7, &val);
> > + if (val & 0x40) {
> > + pfuze100_regulators[id].desc.min_uV = 800000;
> > + pfuze100_regulators[id].desc.uV_step = 50000;
> > + }
> > + }
>
> You should really be doing this on a copy of the regulators table rather
> than on the table itself.
>
everyone of the four regulators(SW2~SW4) has two different linear voltage table which decided by the specific bit(one regulator ,one different bit) . So will modify the voltage table dynamically before regulator register. I think this way is more simple , although looks little weird and uncomfortable.
> > + for (i = 0; i < pfuze_chip->num_regulators; i++)
> > + regulator_unregister(pfuze_chip->regulators[i]);
> > + kfree(pfuze_chip);
>
> Use devm_kzalloc().
Accept
WARNING: multiple messages have this Message-ID (diff)
From: Robin Gong <b38343@freescale.com>
To: Mark Brown <broonie@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <grant.likely@linaro.org>,
<rob.herring@calxeda.com>, <lgirdwood@gmail.com>,
<shawn.guo@linaro.org>, <devicetree-discuss@lists.ozlabs.org>,
<linux-doc@vger.kernel.org>, <rob@landley.net>
Subject: Re: [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver
Date: Sat, 13 Jul 2013 00:15:12 +0800 [thread overview]
Message-ID: <20130712161511.GA21203@Robin-OptiPlex-780> (raw)
In-Reply-To: <20130712144037.GJ24508@sirena.org.uk>
Mark,
Thanks for your kindly review, please see below comments.
On Fri, Jul 12, 2013 at 03:40:37PM +0100, Mark Brown wrote:
> On Fri, Jul 12, 2013 at 12:54:15PM +0800, Robin Gong wrote:
> > Add pfuze100 regulator driver.
>
> This looks mostly good. A few small issues below but nothing major.
>
> > +enum pfuze_id {
> > + PFUZE_ID_PFUZE100,
> > + PFUZE_ID_INVALID,
> > +};
> > +struct pfuze_chip {
>
> Missing blank line here - there are a few other small coding style
> things, checkpatch should help.
>
Thanks Mark, I will check carefully, although I have run the script...
> > +static struct regulator_ops pfuze100_ldo_regulator_ops;
> > +static struct regulator_ops pfuze100_fixed_regulator_ops;
> > +static struct regulator_ops pfuze100_sw_regulator_ops;
> > +static struct regulator_ops pfuze100_swb_regulator_ops;
>
> Better to just reorder things so that no forward declaration is needed.
>
Accept.
> > +static const int pfuze100_swbst[] = {
> > + 5000000, 5050000, 5100000, 5150000,
> > +};
>
> This looks like a linear map, the steps are all 50mV?
>
Yes, but the swbst regulator share the same define type with the vsnvs regulator, and the later voltage table is not linear, so I use volt_table in swbst regulator . I don't want to add another regulator type for this.
> > + num_regulators = pfuze_get_num_regulators_dt(&client->dev);
> > + if (num_regulators <= 0 && pdata)
> > + num_regulators = pdata->num_regulators;
> > + if (num_regulators <= 0) {
> > + dev_err(&client->dev, "no platform data,please add it!\n");
> > + ret = -EINVAL;
> > + return ret;
>
> You should just register all the regulators rather than only registering
> those that the user explicitly selects. This allows users to inpect the
> current configuration and simplifies the code - for example you don't
> need to count the DT nodes and you can just have a simple array in the
> platform data (see how wm831x does this for an example).
>
Yes, it will simplifies the code, but sometimes we will not use all the regulators on boards, in this case, Is it better that only register the available regulators?
> > + /* SW2~SW4 high bit check and modify the voltage value table */
> > + if (i > PFUZE100_SW1C && i < PFUZE100_SWBST) {
> > + regmap_read(pfuze_chip->regmap, PFUZE100_SW2VOL +
> > + (i - PFUZE100_SW2) * 7, &val);
> > + if (val & 0x40) {
> > + pfuze100_regulators[id].desc.min_uV = 800000;
> > + pfuze100_regulators[id].desc.uV_step = 50000;
> > + }
> > + }
>
> You should really be doing this on a copy of the regulators table rather
> than on the table itself.
>
everyone of the four regulators(SW2~SW4) has two different linear voltage table which decided by the specific bit(one regulator ,one different bit) . So will modify the voltage table dynamically before regulator register. I think this way is more simple , although looks little weird and uncomfortable.
> > + for (i = 0; i < pfuze_chip->num_regulators; i++)
> > + regulator_unregister(pfuze_chip->regulators[i]);
> > + kfree(pfuze_chip);
>
> Use devm_kzalloc().
Accept
next prev parent reply other threads:[~2013-07-12 16:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-12 4:54 [PATCH v2] regulator: pfuze100: add pfuze100 regulator driver Robin Gong
2013-07-12 4:54 ` Robin Gong
[not found] ` <1373604855-17714-1-git-send-email-b38343-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2013-07-12 14:40 ` Mark Brown
2013-07-12 14:40 ` Mark Brown
2013-07-12 16:15 ` Robin Gong [this message]
2013-07-12 16:15 ` Robin Gong
2013-07-15 15:09 ` Mark Brown
2013-07-15 1:22 ` Shawn Guo
2013-07-15 1:22 ` Shawn Guo
2013-07-15 6:40 ` Robin Gong
2013-07-15 6:40 ` Robin Gong
2013-07-15 6:49 ` Shawn Guo
2013-07-15 6:49 ` Shawn Guo
-- strict thread matches above, loose matches on Subject: below --
2013-07-12 4:36 Robin Gong
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=20130712161511.GA21203@Robin-OptiPlex-780 \
--to=b38343@freescale.com \
--cc=broonie@kernel.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=shawn.guo@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 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.