From: Mark Brown <broonie@kernel.org>
To: Adrien Grassein <adrien.grassein@gmail.com>
Cc: lgirdwood@gmail.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
troy.kisky@boundarydevices.com, gary.bisson@boundarydevices.com
Subject: Re: [PATCH v2 2/2] regulator: pf8x00: add support of nxp pf8x00 regulator
Date: Fri, 11 Dec 2020 15:28:20 +0000 [thread overview]
Message-ID: <20201211152820.GE4929@sirena.org.uk> (raw)
In-Reply-To: <20201210221629.17312-2-adrien.grassein@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2707 bytes --]
On Thu, Dec 10, 2020 at 11:16:29PM +0100, Adrien Grassein wrote:
> + { .compatible = "nxp,pf8200",},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, pf8x_dt_ids);
> +
> +const struct id_name id_list[] = {
> + {PF8100, "PF8100"},
> + {PF8121A, "PF8121A"},
> + {PF8200, "PF8200"},
> + {0, "???"},
> +};
It's strange to see the list terminated with this ??? entry - these
things usually have a NULL for both the ID and the string. The string
on the terminator is never used so may as well stick with the usual
pattern.
> +static int encode_phase(struct pf8x_chip *pf, int phase)
> +{
> + int ph;
> +
> + if (phase < 0)
> + return -1;
> +
> + ph = phase / 45;
> + if ((ph * 45) != phase) {
> + dev_err(pf->dev, "ignoring, illegal phase %d\n", phase);
> + return -1;
> + }
> +
> + return (ph >= 1) ? ph - 1 : 7;
As I said on the previousl review please write normal condidional
statements to improve the legibility of the code.
> +static inline struct regulator_init_data *match_init_data(int index)
> +{
> + return pf8x00_matches[index].init_data;
> +}
> +
> +static inline struct device_node *match_of_node(int index)
> +{
> + return pf8x00_matches[index].of_node;
> +}
If you need these your driver has a problem, as previously advised
please use the standard DT parsing support.
> + memcpy(pf->regulator_descs, pf8x00_regulators,
> + sizeof(pf->regulator_descs));
Why do you need to take a copy of this? The descriptors should not be
being modified.
> + num_regulators = ARRAY_SIZE(pf->regulator_descs);
> + for (i = 0; i < num_regulators; i++) {
> + struct regulator_init_data *init_data;
> + struct regulator_desc *desc;
> +
> + desc = &pf->regulator_descs[i].desc;
> + init_data = match_init_data(i);
> +
> + config.dev = &client->dev;
> + config.init_data = init_data;
> + config.driver_data = pf;
> + config.of_node = match_of_node(i);
> + config.ena_gpiod = NULL;
You've not done anything to parse the init data (which is good) so the
init data handling is at best redundant.
> + if ((i >= REG_SW1) && (i <= REG_SW7)) {
> + if (mask) {
> + ret = regmap_update_bits(pf->regmap, reg, mask,
> + val);
> + }
> +
> + if (fast_slew > 1) {
> + ret = regmap_read(pf->regmap, reg, &fast_slew);
> + fast_slew &= 0x20;
> + if (ret < 0)
> + fast_slew = 0;
> + pf->regulator_descs[i].fast_slew = fast_slew >> 5;
> + }
May as well just write configurations out when you parse them, no need
to defer to here and it makes things simpler.
> +module_i2c_driver(pf8x_driver);
> +
> +static void __exit pf8x_exit(void)
> +{
> + i2c_del_driver(&pf8x_driver);
> +}
> +module_exit(pf8x_exit);
Does this build cleanly? module_i2c_driver() does both the add and
delete.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-11 16:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-06 0:26 [PATCH 1/2] dt-bindings: regulator: Add pf8x00 regulator Adrien Grassein
2020-12-06 0:26 ` [PATCH 2/2] regulator: pf8x00: add support of nxp " Adrien Grassein
2020-12-07 14:08 ` Mark Brown
2020-12-07 20:36 ` kernel test robot
2020-12-07 13:55 ` [PATCH 1/2] dt-bindings: regulator: Add " Mark Brown
2020-12-10 22:24 ` Adrien Grassein
2020-12-11 13:25 ` Mark Brown
2020-12-10 3:35 ` Rob Herring
2020-12-10 22:16 ` [PATCH v2 1/2] dt-bindings: regulator: add pf8x00 PMIC Adrien Grassein
2020-12-10 22:16 ` [PATCH v2 2/2] regulator: pf8x00: add support of nxp pf8x00 regulator Adrien Grassein
2020-12-11 15:28 ` Mark Brown [this message]
2020-12-11 14:04 ` [PATCH v2 1/2] dt-bindings: regulator: add pf8x00 PMIC Mark Brown
2020-12-12 22:43 ` Adrien Grassein
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=20201211152820.GE4929@sirena.org.uk \
--to=broonie@kernel.org \
--cc=adrien.grassein@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=gary.bisson@boundarydevices.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=troy.kisky@boundarydevices.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;
as well as URLs for NNTP newsgroup(s).