From: andy.shevchenko@gmail.com
To: Esteban Blanc <eblanc@baylibre.com>
Cc: linus.walleij@linaro.org, lgirdwood@gmail.com,
broonie@kernel.org, a.zummo@towertech.it,
alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-rtc@vger.kernel.org,
jpanis@baylibre.com, jneanne@baylibre.com,
aseketeli@baylibre.com, u-kumar1@ti.com
Subject: Re: [PATCH v5 3/3] regulator: tps6594-regulator: Add driver for TI TPS6594 regulators
Date: Tue, 23 May 2023 22:33:50 +0300 [thread overview]
Message-ID: <ZG0VHnEByyMW9i4a@surfacebook> (raw)
In-Reply-To: <20230522163115.2592883-4-eblanc@baylibre.com>
Mon, May 22, 2023 at 06:31:15PM +0200, Esteban Blanc kirjoitti:
> From: Jerome Neanne <jneanne@baylibre.com>
>
> This patch adds support for TPS6594 regulators (bucks and LDOs).
BUCKs (otherwise $$$?)
> The output voltages are configurable and are meant to supply power
> to the main processor and other components.
> Bucks can be used in single or multiphase mode, depending on PMIC
BUCKs (otherwise $$$?)
> part number.
...
> + help
> + This driver supports TPS6594 voltage regulator chips.
> + TPS6594 series of PMICs have 5 BUCKs and 4 LDOs
> + voltage regulators.
> + BUCKs 1,2,3,4 can be used in single phase or multiphase mode.
> + Part number defines which single or multiphase mode is i used.
i?!
> + It supports software based voltage control
> + for different voltage domains.
...
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
Are you sure this one is correct and / or of.h is not missing? of_match_ptr()
IIRC is defined in of.h.
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/driver.h>
> +#include <linux/regulator/machine.h>
> +#include <linux/regulator/of_regulator.h>
...
> +/* Operations permitted on BUCK1/2/3/4/5 */
> +static const struct regulator_ops tps6594_bucks_ops = {
> + .is_enabled = regulator_is_enabled_regmap,
> + .enable = regulator_enable_regmap,
> + .disable = regulator_disable_regmap,
> + .get_voltage_sel = regulator_get_voltage_sel_regmap,
> + .set_voltage_sel = regulator_set_voltage_sel_regmap,
> + .list_voltage = regulator_list_voltage_linear_range,
> + .map_voltage = regulator_map_voltage_linear_range,
> + .set_voltage_time_sel = regulator_set_voltage_time_sel,
> +
Redundant blank line.
> +};
...
> + int error;
> +
> + for (j = 0; j < REGS_INT_NB; j++) {
> + irq_type = &tps6594_regs_irq_types[j];
> + irq = platform_get_irq_byname(pdev, irq_type->irq_name);
> + if (irq < 0)
> + return -EINVAL;
> +
> + irq_data[*irq_idx + j].dev = tps->dev;
> + irq_data[*irq_idx + j].type = irq_type;
> + irq_data[*irq_idx + j].rdev = rdev;
> +
> + error = devm_request_threaded_irq(tps->dev, irq, NULL,
> + tps6594_regulator_irq_handler,
> + IRQF_ONESHOT,
> + irq_type->irq_name,
> + &irq_data[*irq_idx]);
> + (*irq_idx)++;
This is interesing. So, even in error case we touch given parameter. Usually
the pattern is not to touch the output if we know there is an error.
> + if (error) {
> + dev_err(tps->dev, "tps6594 failed to request %s IRQ %d: %d\n",
> + irq_type->irq_name, irq, error);
> + return error;
> + }
> + }
...
> + u8 buck_configured[BUCK_NB] = { 0 };
> + u8 buck_multi[MULTI_PHASE_NB] = { 0 };
0:s are not needed but I dunno if it's a style in the regulator subsystem.
> + static const char * const multiphases[] = {"buck12", "buck123", "buck1234", "buck34"};
> + static const char *npname;
> + int error, i, irq, multi, delta;
> + int irq_idx = 0;
> + int buck_idx = 0;
> + int ext_reg_irq_nb = 2;
> +
Redundant blank line.
> + enum {
> + MULTI_BUCK12,
> + MULTI_BUCK123,
> + MULTI_BUCK1234,
> + MULTI_BUCK12_34,
> + MULTI_FIRST = MULTI_BUCK12,
> + MULTI_LAST = MULTI_BUCK12_34,
> + MULTI_NUM = MULTI_LAST - MULTI_FIRST + 1
MULT_NUM
will suffice instead all this.
> + };
But why enum at all? See below.
...
> + /*
> + * Switch case defines different possible multi phase config
> + * This is based on dts buck node name.
> + * Buck node name must be chosen accordingly.
> + * Default case is no Multiphase buck.
> + * In case of Multiphase configuration, value should be defined for
> + * buck_configured to avoid creating bucks for every buck in multiphase
> + */
> + for (multi = MULTI_FIRST; multi < MULTI_NUM; multi++) {
> + np = of_find_node_by_name(tps->dev->of_node, multiphases[multi]);
> + npname = of_node_full_name(np);
> + np_pmic_parent = of_get_parent(of_get_parent(np));
> + if (of_node_cmp(of_node_full_name(np_pmic_parent), tps->dev->of_node->full_name))
Why not of_node_full_name() in the second case?
> + continue;
> + delta = strcmp(npname, multiphases[multi]);
> + if (!delta) {
> + switch (multi) {
> + case MULTI_BUCK12:
This all looks like match_string() reinvention.
> + buck_multi[0] = 1;
> + buck_configured[0] = 1;
> + buck_configured[1] = 1;
> + break;
> + /* multiphase buck34 is supported only with buck12 */
> + case MULTI_BUCK12_34:
> + buck_multi[0] = 1;
> + buck_multi[1] = 1;
> + buck_configured[0] = 1;
> + buck_configured[1] = 1;
> + buck_configured[2] = 1;
> + buck_configured[3] = 1;
> + break;
> + case MULTI_BUCK123:
> + buck_multi[2] = 1;
> + buck_configured[0] = 1;
> + buck_configured[1] = 1;
> + buck_configured[2] = 1;
> + break;
> + case MULTI_BUCK1234:
> + buck_multi[3] = 1;
> + buck_configured[0] = 1;
> + buck_configured[1] = 1;
> + buck_configured[2] = 1;
> + buck_configured[3] = 1;
> + break;
> + }
> + }
> + }
...
> + irq_data = devm_kmalloc_array(tps->dev,
> + REGS_INT_NB * sizeof(struct tps6594_regulator_irq_data),
> + ARRAY_SIZE(tps6594_bucks_irq_types) +
> + ARRAY_SIZE(tps6594_ldos_irq_types),
> + GFP_KERNEL);
Have you checked overflow.h? There are macros to help with the above calculus.
> + if (!irq_data)
> + return -ENOMEM;
...
> + rdev = devm_regulator_register(&pdev->dev, &multi_regs[i], &config);
> + if (IS_ERR(rdev))
> + return dev_err_probe(tps->dev, PTR_ERR(rdev),
Why not &pdev->dev here?
> + "failed to register %s regulator\n",
> + pdev->name);
...
> + rdev = devm_regulator_register(&pdev->dev, &buck_regs[i], &config);
> + if (IS_ERR(rdev))
> + return dev_err_probe(tps->dev, PTR_ERR(rdev),
> + "failed to register %s regulator\n",
> + pdev->name);
Hmm... Again, why the error is printed against different device than regulator
registration?
...
> + /* LP8764 dosen't have LDO */
> + if (tps->chip_id != LP8764) {
> + for (i = 0; i < ARRAY_SIZE(ldo_regs); i++) {
> + rdev = devm_regulator_register(&pdev->dev, &ldo_regs[i], &config);
> + if (IS_ERR(rdev))
> + return dev_err_probe(tps->dev, PTR_ERR(rdev),
> + "failed to register %s regulator\n",
> + pdev->name);
> +
> + error = tps6594_request_reg_irqs(pdev, rdev, irq_data,
> + tps6594_ldos_irq_types[i],
> + &irq_idx);
> + if (error)
> + return error;
> + }
> + }
> +
> + if (tps->chip_id == LP8764)
'else'?
Or actually
if (tps->chip_id == LP8764) {
...
} else {
the above part
}
?
> + ext_reg_irq_nb = ARRAY_SIZE(tps6594_ext_regulator_irq_types);
...
> +static struct platform_driver tps6594_regulator_driver = {
> + .driver = {
> + .name = "tps6594-regulator",
> + },
> + .probe = tps6594_regulator_probe,
> +};
> +
This blank line is not needed.
> +module_platform_driver(tps6594_regulator_driver);
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-05-23 19:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 16:31 [PATCH v5 0/3] TI TPS6594 PMIC support (RTC, pinctrl, regulators) Esteban Blanc
2023-05-22 16:31 ` [PATCH v5 1/3] rtc: tps6594: Add driver for TPS6594 RTC Esteban Blanc
2023-05-23 13:36 ` andy.shevchenko
2023-05-23 14:32 ` Alexandre Belloni
2023-05-25 13:56 ` Esteban Blanc
2023-05-22 16:31 ` [PATCH v5 2/3] pinctrl: tps6594: Add driver for TPS6594 pinctrl and GPIOs Esteban Blanc
2023-05-23 19:14 ` andy.shevchenko
2023-05-25 14:07 ` Esteban Blanc
2023-05-26 18:43 ` Andy Shevchenko
2023-05-31 7:58 ` Esteban Blanc
2023-05-22 16:31 ` [PATCH v5 3/3] regulator: tps6594-regulator: Add driver for TI TPS6594 regulators Esteban Blanc
2023-05-23 19:33 ` andy.shevchenko [this message]
2023-06-07 11:44 ` jerome Neanne
2023-06-07 14:52 ` Andy Shevchenko
2023-06-06 16:51 ` [PATCH v5 0/3] TI TPS6594 PMIC support (RTC, pinctrl, regulators) Mark Brown
2023-06-07 12:40 ` (subset) " Mark Brown
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=ZG0VHnEByyMW9i4a@surfacebook \
--to=andy.shevchenko@gmail.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=aseketeli@baylibre.com \
--cc=broonie@kernel.org \
--cc=eblanc@baylibre.com \
--cc=jneanne@baylibre.com \
--cc=jpanis@baylibre.com \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=u-kumar1@ti.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