From: Mark Brown <broonie@kernel.org>
To: Chen Feng <puck.chen@hisilicon.com>
Cc: lee.jones@linaro.org, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, yudongbin@hisilicon.com,
saberlily.xia@hisilicon.com, suzhuangluan@hisilicon.com,
kong.kongxinwei@hisilicon.com, xuyiping@hisilicon.com,
z.liuxinliang@hisilicon.com, puck.chenfeng@gmail.com,
weidong2@hisilicon.com, w.f@huawei.com, qijiwen@hisilicon.com,
peter.panshilin@hisilicon.com, dan.zhao@hisilicon.com,
linuxarm@huawei.com, liguozhu@hisilicon.com,
shimingxing@hisilicon.com, albert.lubing@hisilicon.com,
oliver.fu@hisilicon.com, haojian.zhuang@linaro.org
Subject: Re: [PATCH v4 4/5] regulator: add regulator driver of hi655x pmic
Date: Tue, 5 Jan 2016 15:44:31 +0000 [thread overview]
Message-ID: <20160105154431.GB6588@sirena.org.uk> (raw)
In-Reply-To: <1451910472-126417-5-git-send-email-puck.chen@hisilicon.com>
[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]
On Mon, Jan 04, 2016 at 08:27:51PM +0800, Chen Feng wrote:
> +/*LDO 2 & LDO 14*/
Please use the normal kernel coding style for comments, I'm surprised
checkpatch didn't warn you about this.
> +static const unsigned int ldo2_voltages[] = {
> + 2500000, 2600000, 2700000, 2800000,
> + 2900000, 3000000, 3100000, 3200000,
This looks like a linear range from 2.5V in steps of 100mV? A linear
range is better than a table since values can be mapped directly without
having to scan a table.
> +/*LDO7 & LDO10*/
> +static const unsigned int ldo7_voltages[] = {
> + 1800000, 1850000, 2850000, 2900000,
> + 3000000, 3100000, 3200000, 3300000,
This is the sort of thing a voltage table is for where the voltages
aren't evenly spaced and don't map onto a formula.
> +static const struct of_device_id of_hi655x_regulator_match_tbl[] = {
> + {
> + .compatible = "hisilicon,hi655x-regulator",
> + },
> +};
> +MODULE_DEVICE_TABLE(of, of_hi655x_regulator_match_tbl);
A couple of problems here. One is that the compatible strings should be
for specific devices, not use a wildcard. The other is that since this
is part of a PMIC and we already have a compatible string for the PMIC
so this is really just a set of properties for that device rather than a
totally separate device - we're not achieving any real reuse over
multiple devices or anything.
> + for (i = 0; i < ARRAY_SIZE(regulators); i++) {
> + if (!of_node_cmp(np->name, regulators[i].rdesc.name))
> + break;
> + }
> +
> + if (i == ARRAY_SIZE(regulators)) {
> + dev_err(dev, "error regulator %s int dts\n", np->name);
> + return -ENODEV;
> + }
> +
> + regulator = ®ulators[i];
> + init_data = of_get_regulator_init_data(dev, np,
> + ®ulator->rdesc);
> + if (!init_data)
> + return -EINVAL;
Don't open code this, use the standard support with of_match and
regulators_node.
> + config.dev = dev;
> + config.init_data = init_data;
> + config.driver_data = regulator;
> + config.regmap = pmic->regmap;
> + config.of_node = pdev->dev.of_node;
> + rdev = devm_regulator_register(dev, ®ulator->rdesc,
> + &config);
> + if (IS_ERR(rdev))
> + return PTR_ERR(rdev);
Though this looks like it's trying to have a device per regulator which
is an unusual pattern and if we are doing that then relying on the node
name to figure out which device this is a bit broken.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-01-05 15:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 12:27 [PATCH v4 0/5] Add Support for Hi6220 PMIC Hi6553 MFD Core Chen Feng
2016-01-04 12:27 ` [PATCH v4 1/5] doc: bindings: Add document for mfd hi665x PMIC Chen Feng
2016-01-04 12:27 ` [PATCH v4 2/5] doc: bindings: Document for hi655x regulator driver Chen Feng
2016-01-05 15:47 ` Mark Brown
2016-01-07 3:36 ` chenfeng
2016-01-04 12:27 ` [PATCH v4 3/5] mfd: hi655x: Add hi665x pmic driver Chen Feng
2016-01-04 18:45 ` kbuild test robot
2016-01-04 20:02 ` kbuild test robot
2016-01-11 5:49 ` Lee Jones
2016-01-04 12:27 ` [PATCH v4 4/5] regulator: add regulator driver of hi655x pmic Chen Feng
2016-01-05 15:44 ` Mark Brown [this message]
2016-01-07 3:35 ` chenfeng
2016-01-04 12:27 ` [PATCH v4 5/5] hisilicon/dts: Add hi655x pmic dts node Chen Feng
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=20160105154431.GB6588@sirena.org.uk \
--to=broonie@kernel.org \
--cc=albert.lubing@hisilicon.com \
--cc=dan.zhao@hisilicon.com \
--cc=haojian.zhuang@linaro.org \
--cc=kong.kongxinwei@hisilicon.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=liguozhu@hisilicon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=oliver.fu@hisilicon.com \
--cc=peter.panshilin@hisilicon.com \
--cc=puck.chen@hisilicon.com \
--cc=puck.chenfeng@gmail.com \
--cc=qijiwen@hisilicon.com \
--cc=saberlily.xia@hisilicon.com \
--cc=shimingxing@hisilicon.com \
--cc=suzhuangluan@hisilicon.com \
--cc=w.f@huawei.com \
--cc=weidong2@hisilicon.com \
--cc=xuyiping@hisilicon.com \
--cc=yudongbin@hisilicon.com \
--cc=z.liuxinliang@hisilicon.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®