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
next prev parent 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: linkBe 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.