Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Fabien Parent <fparent@baylibre.com>
Cc: robh+dt@kernel.org, mark.rutland@arm.com, matthias.bgg@gmail.com,
	lee.jones@linaro.org, lgirdwood@gmail.com,
	dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 5/7] regulator: mt6392: Add support for MT6392 regulator
Date: Wed, 19 Jun 2019 18:23:22 +0100	[thread overview]
Message-ID: <20190619172322.GX5316@sirena.org.uk> (raw)
In-Reply-To: <20190619142013.20913-6-fparent@baylibre.com>

[-- Attachment #1: Type: text/plain, Size: 4341 bytes --]

On Wed, Jun 19, 2019 at 04:20:11PM +0200, Fabien Parent wrote:

> connectcts as a slave to a SoC using SPI, wrapped inside PWRAP.
> 
> Signed-off-by: Fabien Parent <fparent@baylibre.com>

This has your signoff...

> +++ b/drivers/regulator/mt6392-regulator.c
> @@ -0,0 +1,490 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Author: Chen Zhong <chen.zhong@mediatek.com>
> + */

...but someone else from a different company wrote it?  Also please make
the entire header a C++ one so this looks more consistent.

> +static const u32 ldo_volt_table2[] = {
> +	3300000, 3400000, 3500000, 3600000,
> +};

This looks like a linear range?

> +static int mt6392_get_status(struct regulator_dev *rdev)
> +{
> +	int ret;
> +	u32 regval;
> +	struct mt6392_regulator_info *info = rdev_get_drvdata(rdev);
> +
> +	ret = regmap_read(rdev->regmap, info->desc.enable_reg, &regval);
> +	if (ret != 0) {
> +		dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
> +}

This appears to just be reading back the enable bit, the status
operation should only be implemented if it can check if the regulator
is actually working.

Please also don't use the ternery operator needlessly, just write normal
conditional statements to help people read the code.

> +static int mt6392_buck_set_mode(struct regulator_dev *rdev, unsigned int mode)
> +{
> +	int ret, val = 0;
> +	struct mt6392_regulator_info *info = rdev_get_drvdata(rdev);
> +	u32 reg_value;
> +
> +	if (!info->modeset_mask) {
> +		dev_err(&rdev->dev, "regulator %s doesn't support set_mode\n",
> +			info->desc.name);
> +		return -EINVAL;
> +	}

If a regulator doesn't have support for set_mode() the operation
shouldn't be provided for it.

> +	ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
> +				  info->modeset_mask, val);
> +
> +	if (regmap_read(rdev->regmap, info->modeset_reg, &reg_value) < 0) {
> +		dev_err(&rdev->dev, "Failed to read register value\n");
> +		return -EIO;
> +	}

Why are we doing this read?  It's not like anything even looks at the
value.

> +static int mt6392_set_buck_vosel_reg(struct platform_device *pdev)
> +{
> +	struct mt6397_chip *mt6392 = dev_get_drvdata(pdev->dev.parent);
> +	int i;
> +	u32 regval;
> +
> +	for (i = 0; i < MT6392_MAX_REGULATOR; i++) {
> +		if (mt6392_regulators[i].vselctrl_reg) {
> +			if (regmap_read(mt6392->regmap,
> +				mt6392_regulators[i].vselctrl_reg,
> +				&regval) < 0) {
> +				dev_err(&pdev->dev,
> +					"Failed to read buck ctrl\n");
> +				return -EIO;
> +			}

The indentation here is seriously messed up, parts of the conditional
statement are indented as far as the code block inside the conditional
statement - usually the continuation of the condition would align with
the (.

> +
> +			if (regval & mt6392_regulators[i].vselctrl_mask) {
> +				mt6392_regulators[i].desc.vsel_reg =
> +				mt6392_regulators[i].vselon_reg;
> +			}

Again here the indentation is weird, this is actually one statement in
the { } but the second line isn't indented.

I'm also not altogether clear why this function is doing what it's
doing, some comments or something would be good at least.

> +		/* Constrain board-specific capabilities according to what
> +		 * this driver and the chip itself can actually do.
> +		 */
> +		c = rdev->constraints;
> +		c->valid_modes_mask |= REGULATOR_MODE_NORMAL|
> +			REGULATOR_MODE_STANDBY | REGULATOR_MODE_FAST;
> +		c->valid_ops_mask |= REGULATOR_CHANGE_MODE;

This is broken, the driver should absolutely not modify constraints.
The driver isn't even doing what the comment says here, it's enabling
permissions regardless of if they were enabled by the machine.

> +static const struct of_device_id mt6392_of_match[] = {
> +	{ .compatible = "mediatek,mt6392-regulator", },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, mt6392_of_match);

There is no need for a compatible for this subfunction, it's specific to
a single chip so we should be able to enumerate it just by enumerating
that chip and this way of binding regulators is very Linux specific.
Just have the MFD register the regulator device.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-06-19 17:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 14:20 [PATCH v4 0/7] mt6392: Add support for MediaTek MT6392 PMIC Fabien Parent
2019-06-19 14:20 ` [PATCH v4 1/7] dt-bindings: regulator: add support for MT6392 Fabien Parent
     [not found] ` <20190619142013.20913-1-fparent-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2019-06-19 14:20   ` [PATCH v4 2/7] dt-bindings: mfd: mt6397: Add bindings for MT6392 PMIC Fabien Parent
2019-06-19 14:20 ` [PATCH v4 3/7] dt-bindings: input: mtk-pmic-keys: add MT6392 binding definition Fabien Parent
2019-06-19 14:20 ` [PATCH v4 4/7] mfd: mt6397: Add support for MT6392 pmic Fabien Parent
2019-06-19 14:20 ` [PATCH v4 5/7] regulator: mt6392: Add support for MT6392 regulator Fabien Parent
2019-06-19 17:23   ` Mark Brown [this message]
2019-06-19 14:20 ` [PATCH v4 6/7] input: keyboard: mtk-pmic-keys: add MT6392 support Fabien Parent
2019-06-19 14:20 ` [PATCH v4 7/7] arm64: dts: mt6392: Add PMIC mt6392 dtsi Fabien Parent

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=20190619172322.GX5316@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=fparent@baylibre.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox