All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Rob Herring <robh+dt@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/5] iio:adc:lpc32xx Add scale feature
Date: Sat, 9 Feb 2019 17:23:03 +0000	[thread overview]
Message-ID: <20190209172303.43cff3ec@archlinux> (raw)
In-Reply-To: <20190208160944.13281-6-gregory.clement@bootlin.com>

On Fri,  8 Feb 2019 17:09:44 +0100
Gregory CLEMENT <gregory.clement@bootlin.com> wrote:

> Until now this driver only exposed the raw value of the channels. With
> this patch, the scale value is also exposed.
> 
> It depends of a regulator supply, and unlike most of the other driver, do
> not having this regulator won't prevent to use the driver. The reason for
> it is to allow to continue to use this driver with an old device tree. If
> there is no regulator supply then the scale won't be exposed.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Hi Gregory,

A few minor comments inline.

I'll admit to being surprised to see any patches at all for this driver given
how long it has been since we had any known users.  We nearly dropped it as
unused years ago IIRC!  Good thing we didn't it seems.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/lpc32xx_adc.c | 27 +++++++++++++++++++++++----
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/lpc32xx_adc.c b/drivers/iio/adc/lpc32xx_adc.c
> index f391c1e10136..e36ca307f065 100644
> --- a/drivers/iio/adc/lpc32xx_adc.c
> +++ b/drivers/iio/adc/lpc32xx_adc.c
> @@ -14,6 +14,7 @@
>  #include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
>  
>  /*
>   * LPC32XX registers definitions
> @@ -45,6 +46,7 @@ struct lpc32xx_adc_state {
>  	void __iomem *adc_base;
>  	struct clk *clk;
>  	struct completion completion;
> +	struct regulator *vref;
>  
>  	u32 value;
>  };
> @@ -57,7 +59,9 @@ static int lpc32xx_read_raw(struct iio_dev *indio_dev,
>  {
>  	struct lpc32xx_adc_state *st = iio_priv(indio_dev);
>  	int ret;
> -	if (mask == IIO_CHAN_INFO_RAW) {
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
>  		mutex_lock(&indio_dev->mlock);
>  		ret = clk_prepare_enable(st->clk);
>  		if (ret) {
> @@ -77,6 +81,12 @@ static int lpc32xx_read_raw(struct iio_dev *indio_dev,
>  		mutex_unlock(&indio_dev->mlock);
>  
>  		return IIO_VAL_INT;
> +
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = regulator_get_voltage(st->vref) / 1000;
> +		*val2 =  chan->scan_type.realbits;
> +
> +		return IIO_VAL_FRACTIONAL_LOG2;

Please add a default, otherwise we are going to get some compiler
warnings that are irritating as it will think we 'forgot' to handle
the other cases.

>  	}
>  
>  	return -EINVAL;
> @@ -93,9 +103,10 @@ static const struct iio_info lpc32xx_adc_iio_info = {
>  	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),	\
>  	.address = LPC32XXAD_IN * _index,		\
>  	.scan_index = _index,				\
> +	.scan_type.realbits = 10			\

Given scan_type is only used in the core in buffered modes
that this driver doesn't support this is a little 'unusual'.

Also, only one value, so why bother rather than just putting it
in the one place it is used?

>  }
>  
> -static const struct iio_chan_spec lpc32xx_adc_iio_channels[] = {
> +static struct iio_chan_spec lpc32xx_adc_iio_channels[] = {
Please provide two const versions and pick between them rather than
modifying the one.

Clearly we might 'know' there is only ever one such ADC on these devices
but it's not obvious to a reviewer who isn't familiar with the hardware,
making this look like a bug.

>  	LPC32XX_ADC_CHANNEL(0),
>  	LPC32XX_ADC_CHANNEL(1),
>  	LPC32XX_ADC_CHANNEL(2),
> @@ -119,7 +130,7 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
>  	struct resource *res;
>  	int retval = -ENODEV;
>  	struct iio_dev *iodev = NULL;
> -	int irq;
> +	int irq, i;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res) {
> @@ -159,6 +170,15 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
>  		return retval;
>  	}
>  
> +	st->vref = devm_regulator_get(&pdev->dev, "vref");
> +	if (IS_ERR(st->vref))
> +		dev_err(&pdev->dev,
> +			"Missing vref regulator: No scaling available\n");
> +	else
> +		for (i = 0; i <  ARRAY_SIZE(lpc32xx_adc_iio_channels); i++)
> +			lpc32xx_adc_iio_channels[i].info_mask_shared_by_type =
> +				BIT(IIO_CHAN_INFO_SCALE);
> +
>  	platform_set_drvdata(pdev, iodev);
>  
>  	init_completion(&st->completion);
> @@ -175,7 +195,6 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
>  		return retval;
>  
>  	dev_info(&pdev->dev, "LPC32XX ADC driver loaded, IRQ %d\n", irq);
> -
Unrelated (and in my view) bad whitespace change.
>  	return 0;
>  }
>  

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23@kernel.org>
To: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Rob Herring <robh+dt@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/5] iio:adc:lpc32xx Add scale feature
Date: Sat, 9 Feb 2019 17:23:03 +0000	[thread overview]
Message-ID: <20190209172303.43cff3ec@archlinux> (raw)
In-Reply-To: <20190208160944.13281-6-gregory.clement@bootlin.com>

On Fri,  8 Feb 2019 17:09:44 +0100
Gregory CLEMENT <gregory.clement@bootlin.com> wrote:

> Until now this driver only exposed the raw value of the channels. With
> this patch, the scale value is also exposed.
> 
> It depends of a regulator supply, and unlike most of the other driver, do
> not having this regulator won't prevent to use the driver. The reason for
> it is to allow to continue to use this driver with an old device tree. If
> there is no regulator supply then the scale won't be exposed.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Hi Gregory,

A few minor comments inline.

I'll admit to being surprised to see any patches at all for this driver given
how long it has been since we had any known users.  We nearly dropped it as
unused years ago IIRC!  Good thing we didn't it seems.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/lpc32xx_adc.c | 27 +++++++++++++++++++++++----
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/lpc32xx_adc.c b/drivers/iio/adc/lpc32xx_adc.c
> index f391c1e10136..e36ca307f065 100644
> --- a/drivers/iio/adc/lpc32xx_adc.c
> +++ b/drivers/iio/adc/lpc32xx_adc.c
> @@ -14,6 +14,7 @@
>  #include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
>  
>  /*
>   * LPC32XX registers definitions
> @@ -45,6 +46,7 @@ struct lpc32xx_adc_state {
>  	void __iomem *adc_base;
>  	struct clk *clk;
>  	struct completion completion;
> +	struct regulator *vref;
>  
>  	u32 value;
>  };
> @@ -57,7 +59,9 @@ static int lpc32xx_read_raw(struct iio_dev *indio_dev,
>  {
>  	struct lpc32xx_adc_state *st = iio_priv(indio_dev);
>  	int ret;
> -	if (mask == IIO_CHAN_INFO_RAW) {
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
>  		mutex_lock(&indio_dev->mlock);
>  		ret = clk_prepare_enable(st->clk);
>  		if (ret) {
> @@ -77,6 +81,12 @@ static int lpc32xx_read_raw(struct iio_dev *indio_dev,
>  		mutex_unlock(&indio_dev->mlock);
>  
>  		return IIO_VAL_INT;
> +
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = regulator_get_voltage(st->vref) / 1000;
> +		*val2 =  chan->scan_type.realbits;
> +
> +		return IIO_VAL_FRACTIONAL_LOG2;

Please add a default, otherwise we are going to get some compiler
warnings that are irritating as it will think we 'forgot' to handle
the other cases.

>  	}
>  
>  	return -EINVAL;
> @@ -93,9 +103,10 @@ static const struct iio_info lpc32xx_adc_iio_info = {
>  	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),	\
>  	.address = LPC32XXAD_IN * _index,		\
>  	.scan_index = _index,				\
> +	.scan_type.realbits = 10			\

Given scan_type is only used in the core in buffered modes
that this driver doesn't support this is a little 'unusual'.

Also, only one value, so why bother rather than just putting it
in the one place it is used?

>  }
>  
> -static const struct iio_chan_spec lpc32xx_adc_iio_channels[] = {
> +static struct iio_chan_spec lpc32xx_adc_iio_channels[] = {
Please provide two const versions and pick between them rather than
modifying the one.

Clearly we might 'know' there is only ever one such ADC on these devices
but it's not obvious to a reviewer who isn't familiar with the hardware,
making this look like a bug.

>  	LPC32XX_ADC_CHANNEL(0),
>  	LPC32XX_ADC_CHANNEL(1),
>  	LPC32XX_ADC_CHANNEL(2),
> @@ -119,7 +130,7 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
>  	struct resource *res;
>  	int retval = -ENODEV;
>  	struct iio_dev *iodev = NULL;
> -	int irq;
> +	int irq, i;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res) {
> @@ -159,6 +170,15 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
>  		return retval;
>  	}
>  
> +	st->vref = devm_regulator_get(&pdev->dev, "vref");
> +	if (IS_ERR(st->vref))
> +		dev_err(&pdev->dev,
> +			"Missing vref regulator: No scaling available\n");
> +	else
> +		for (i = 0; i <  ARRAY_SIZE(lpc32xx_adc_iio_channels); i++)
> +			lpc32xx_adc_iio_channels[i].info_mask_shared_by_type =
> +				BIT(IIO_CHAN_INFO_SCALE);
> +
>  	platform_set_drvdata(pdev, iodev);
>  
>  	init_completion(&st->completion);
> @@ -175,7 +195,6 @@ static int lpc32xx_adc_probe(struct platform_device *pdev)
>  		return retval;
>  
>  	dev_info(&pdev->dev, "LPC32XX ADC driver loaded, IRQ %d\n", irq);
> -
Unrelated (and in my view) bad whitespace change.
>  	return 0;
>  }
>  


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-02-09 17:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 16:09 [PATCH 0/5] Adding scale support to the lpc32xx ADC driver Gregory CLEMENT
2019-02-08 16:09 ` Gregory CLEMENT
2019-02-08 16:09 ` [PATCH 1/5] dt-bindings: iio: adc: move lpc32xx-adc out of staging Gregory CLEMENT
2019-02-08 16:09   ` Gregory CLEMENT
2019-02-09 17:05   ` Jonathan Cameron
2019-02-09 17:05     ` Jonathan Cameron
2019-02-09 17:05     ` Jonathan Cameron
2019-02-08 16:09 ` [PATCH 2/5] dt-bindings: iio: adc: lpc32xx-adc: Document vref-supply Gregory CLEMENT
2019-02-08 16:09   ` Gregory CLEMENT
2019-02-09 17:09   ` Jonathan Cameron
2019-02-09 17:09     ` Jonathan Cameron
2019-02-09 17:09     ` Jonathan Cameron
2019-02-09 18:07   ` Vladimir Zapolskiy
2019-02-09 18:07     ` Vladimir Zapolskiy
2019-02-15 16:07     ` Gregory CLEMENT
2019-02-20 12:11       ` Sylvain Lemieux
2019-02-25 23:32   ` Rob Herring
2019-02-25 23:32     ` Rob Herring
2019-02-08 16:09 ` [PATCH 3/5] iio:adc:lpc32xx use SPDX-License-Identifier Gregory CLEMENT
2019-02-08 16:09   ` Gregory CLEMENT
2019-02-09 17:10   ` Jonathan Cameron
2019-02-09 17:10     ` Jonathan Cameron
2019-02-09 17:10     ` Jonathan Cameron
2019-02-08 16:09 ` [PATCH 4/5] iio:adc:lpc32xx Cleanup headers Gregory CLEMENT
2019-02-08 16:09   ` Gregory CLEMENT
2019-02-09 17:16   ` Jonathan Cameron
2019-02-09 17:16     ` Jonathan Cameron
2019-02-15 15:42     ` Gregory CLEMENT
2019-02-18 14:07       ` Jonathan Cameron
2019-02-18 14:07         ` Jonathan Cameron
2019-02-08 16:09 ` [PATCH 5/5] iio:adc:lpc32xx Add scale feature Gregory CLEMENT
2019-02-08 16:09   ` Gregory CLEMENT
2019-02-09 17:23   ` Jonathan Cameron [this message]
2019-02-09 17:23     ` Jonathan Cameron
2019-02-15 15:35     ` Gregory CLEMENT

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=20190209172303.43cff3ec@archlinux \
    --to=jic23@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregory.clement@bootlin.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzoni@bootlin.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.