linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Christian Hohnstaedt <Christian.Hohnstaedt@wago.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] mfd: tps65218.c: Add input voltage options
Date: Fri, 21 Dec 2018 11:01:28 +0000	[thread overview]
Message-ID: <20181221110128.GO13248@dell> (raw)
In-Reply-To: <1545120356-7749-3-git-send-email-Christian.Hohnstaedt@wago.com>

On Tue, 18 Dec 2018, Christian Hohnstaedt wrote:

> These options apply to all regulators in this chip.
> 
> strict-supply-voltage:
>   Set STRICT flag in CONFIG1
> under-voltage-limit:
>   Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1
> under-voltage-hysteresis:
>   Select 200mV or 400mV UVLOHYS in CONFIG2
> 
> Signed-off-by: Christian Hohnstaedt <Christian.Hohnstaedt@wago.com>
> ---
>  drivers/mfd/tps65218.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)

This needs a close review by Tony and any of the other OMAP guys.

At the very least, please put '\n's between the if() statements.  You
also need to return after an error print, else I suggest it's not an
error.

It would also look tidier if you changed the if()s to one liners to
assign to different variables, then dealt with them separately later
on.  The way it's done here looks messy to say the least.

> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 8bcdecf..f5e559b 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -211,6 +211,50 @@ static const struct of_device_id of_tps65218_match_table[] = {
>  };
>  MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
>  
> +static void tps65218_options(struct tps65218 *tps)
> +{
> +	struct device *dev = tps->dev;
> +	struct device_node *np = dev->of_node;
> +	u32 pval;

What does pval mean?  I suggest just val is more common.

> +	if (!of_property_read_u32(np, "strict-supply-voltage", &pval)) {
> +		tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
> +			TPS65218_CONFIG1_STRICT,
> +			pval ? TPS65218_CONFIG1_STRICT : 0,
> +			TPS65218_PROTECT_L1);
> +		dev_dbg(dev, "tps65218 strict-supply-voltage: %d\n", pval);
> +	}
> +	if (!of_property_read_u32(np, "under-voltage-hysteresis", &pval)) {
> +		if (pval != 400000 && pval != 200000) {
> +			dev_err(dev,
> +				 "under-voltage-hysteresis must be %d or %d\n",
> +				 200000, 400000);
> +		} else {
> +			tps65218_update_bits(tps, TPS65218_REG_CONFIG2,
> +				TPS65218_CONFIG2_UVLOHYS,
> +				pval == 400000 ? TPS65218_CONFIG2_UVLOHYS : 0,
> +				TPS65218_PROTECT_L1);
> +		}
> +		dev_dbg(dev, "tps65218 under-voltage-hysteresis: %d\n", pval);
> +	}
> +	if (!of_property_read_u32(np, "under-voltage-limit", &pval)) {
> +		int i, vals[] = { 275, 295, 325, 335 };
> +
> +		for (i = 0; i < ARRAY_SIZE(vals); i++) {
> +			if (pval == vals[i] * 10000)

Just use the full value in 'vals'.

> +				break;
> +		}

It took me a few seconds to realise what you're doing here.

I think a switch() statement would be cleaner.

You should also #define the values.

TPS65218_UNDER_VOLT_LIM_2750000 0

Etc.

> +		if (i < ARRAY_SIZE(vals)) {
> +			tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
> +				TPS65218_CONFIG1_UVLO_MASK, i,
> +				TPS65218_PROTECT_L1);
> +		} else {
> +			dev_err(dev, "Invalid under-voltage-limit: %d\n", pval);

This could go in the default: section.

> +		}
> +		dev_dbg(dev, "tps65218 under-voltage-limit: %d=%d\n", pval, i);

I suggest considering removing these.

> +	}
> +}
> +
>  static int tps65218_probe(struct i2c_client *client,
>  				const struct i2c_device_id *ids)
>  {
> @@ -249,6 +293,8 @@ static int tps65218_probe(struct i2c_client *client,
>  
>  	tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
>  
> +	tps65218_options(tps);

Options is not good nomenclature as it doesn't really tell us
anything.  Looks like all the values are voltage related to me?

>  	ret = mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO, tps65218_cells,
>  			      ARRAY_SIZE(tps65218_cells), NULL, 0,
>  			      regmap_irq_get_domain(tps->irq_data));

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2018-12-21 11:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  8:05 [PATCH 0/2] Add input voltage configuration for TPS65218 Christian Hohnstaedt
2018-12-18  8:05 ` [PATCH 1/2] dt-bindings: regulator: extend tps65218 bindings Christian Hohnstaedt
2018-12-24  9:15   ` J, KEERTHY
2018-12-28 22:51   ` Rob Herring
2018-12-18  8:05 ` [PATCH 2/2] mfd: tps65218.c: Add input voltage options Christian Hohnstaedt
2018-12-21 11:01   ` Lee Jones [this message]
2018-12-23 16:40     ` Tony Lindgren
2018-12-24  6:32       ` Lee Jones
2018-12-24  9:01         ` J, KEERTHY
2018-12-24  9:38     ` J, KEERTHY
2019-01-03 13:47 ` [PATCH v2 0/2] Add input voltage configuration for TPS65218 Christian Hohnstaedt
2019-01-14  8:16   ` [PATCH v3 " Christian Hohnstaedt
2019-01-14  8:16   ` [PATCH v3 1/2] dt-bindings: regulator: extend tps65218 bindings Christian Hohnstaedt
2019-01-14  8:16   ` [PATCH v3 2/2] mfd: tps65218.c: Add input voltage options Christian Hohnstaedt
2019-01-16 14:13     ` Lee Jones
2019-01-17  5:54       ` Christian Hohnstaedt
2019-01-17  8:07         ` Lee Jones
2019-01-17  8:08     ` Lee Jones
2019-01-03 13:47 ` [PATCH v2 1/2] dt-bindings: regulator: extend tps65218 bindings Christian Hohnstaedt
2019-01-11 16:17   ` Rob Herring
2019-01-03 13:47 ` [PATCH v2 2/2] mfd: tps65218.c: Add input voltage options Christian Hohnstaedt
2019-01-14  6:38   ` Keerthy

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=20181221110128.GO13248@dell \
    --to=lee.jones@linaro.org \
    --cc=Christian.Hohnstaedt@wago.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.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).