devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Chen Wang" <unicorn_wang@outlook.com>,
	"Inochi Amaoto" <inochiama@outlook.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Miquèl Raynal" <miquel.raynal@bootlin.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2 2/3] iio: adc: sophgo-saradc: Add driver for Sophgo SARADC
Date: Sat, 6 Jul 2024 12:10:04 +0100	[thread overview]
Message-ID: <20240706121004.37ee9fb5@jic23-huawei> (raw)
In-Reply-To: <20240705-sg2002-adc-v2-2-83428c20a9b2@bootlin.com>

On Fri, 05 Jul 2024 15:42:24 +0200
Thomas Bonnefille <thomas.bonnefille@bootlin.com> wrote:

> This adds a driver for the common Sophgo SARADC.
> 
> Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
Some more minor feedback inline.

Thanks,

Jonathan

> diff --git a/drivers/iio/adc/sophgo-cv18xx-adc.c b/drivers/iio/adc/sophgo-cv18xx-adc.c
> new file mode 100644
> index 000000000000..dd1188b1923e
> --- /dev/null
> +++ b/drivers/iio/adc/sophgo-cv18xx-adc.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + *  Sophgo CV18XX series SARADC Driver
> + *
> + *  Copyright (C) Bootlin 2024
> + *  Author: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/dev_printk.h>
> +#include <linux/interrupt.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iopoll.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +
> +#define CV18XX_ADC_CTRL_REG			0x04
> +#define		CV18XX_ADC_EN			BIT(0)
> +#define		CV18XX_ADC_SEL(x)		BIT((x)+4)
BIT((x) + 4)

> +#define CV18XX_ADC_STATUS_REG			0x08
> +#define		CV18XX_ADC_BUSY			BIT(0)
> +#define CV18XX_ADC_CYC_SET_REG			0x0C
> +#define		CV18XX_ADC_DEF_CYC_SETTINGS	0xF1F0F

I'd prefer to see that broken up into fields if we have any info
on what they are.

> +#define CV18XX_ADC_CH_RESULT_REG(x)		(0x10+4*(x))
(0x10 + 4 * (x))
code style also applies in macros.

> +#define		CV18XX_ADC_CH_RESULT		0xfff

GENMASK(11, 0)

> +#define		CV18XX_ADC_CH_VALID		BIT(15)
> +#define CV18XX_ADC_INTR_EN_REG			0x20
> +#define CV18XX_ADC_INTR_CLR_REG			0x24
> +#define CV18XX_ADC_INTR_STA_REG			0x28
>
> +
> +static int cv18xx_adc_read_raw(struct iio_dev *indio_dev,
> +				  struct iio_chan_spec const *chan,
> +				  int *val, int *val2, long mask)
> +{
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
{
> +		struct cv18xx_adc *saradc = iio_priv(indio_dev);
> +		u32 sample;
> +		int ret;
> +
> +		scoped_guard(mutex, &saradc->lock) {
> +			cv18xx_adc_start_measurement(saradc, chan->scan_index);
> +			ret = cv18xx_adc_wait(saradc);
> +			if (ret < 0)
> +				return ret;
> +
> +			sample = readl(saradc->regs + CV18XX_ADC_CH_RESULT_REG(chan->scan_index));
> +		}
> +		if (!(sample & CV18XX_ADC_CH_VALID))
> +			return -ENODATA;
> +
> +		*val = sample & CV18XX_ADC_CH_RESULT;
> +		return IIO_VAL_INT;
}

> +	case IIO_CHAN_INFO_SCALE:
> +		*val = 3300;
> +		*val2 = 12;
> +		return IIO_VAL_FRACTIONAL_LOG2;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static irqreturn_t cv18xx_adc_interrupt_handler(int irq, void *private)
> +{
> +	struct cv18xx_adc *saradc = private;
> +
> +	if (!(readl(saradc->regs + CV18XX_ADC_INTR_STA_REG) & BIT(0)))

Add a define for that BIT(0) and use FIELD_GET() to extract it.


> +		return IRQ_NONE;
> +
> +	writel(1, saradc->regs + CV18XX_ADC_INTR_CLR_REG);

Add a define for the 1 here (I guess it's BIT(0)?)
as well to show what is logically being cleared rather than simply
the register value.

> +	complete(&saradc->completion);
> +	return IRQ_HANDLED;
> +}
> +
> +static const struct iio_info cv18xx_adc_info = {
> +	.read_raw = &cv18xx_adc_read_raw,
> +};
> +
> +static int cv18xx_adc_probe(struct platform_device *pdev)
> +{
> +	struct cv18xx_adc *saradc;
> +	struct iio_dev *indio_dev;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*saradc));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	saradc = iio_priv(indio_dev);
> +	indio_dev->name = "sophgo-cv18xx-adc";
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->info = &cv18xx_adc_info;
> +	indio_dev->num_channels = ARRAY_SIZE(sophgo_channels);
> +	indio_dev->channels = sophgo_channels;
> +

One blank line is almost always enough for readability and if you use too many
we get less code on the screen and hence it hurts readability a little.

> +
> +	if (IS_ERR(devm_clk_get_optional_enabled(&pdev->dev, NULL)))
> +		dev_dbg(&pdev->dev, "Can't get clock from device tree, using No-Die domain");

Failure to get a clock is an error and you should exit with a suitable
dev_err_probe().
Getting a NULL answer from this call reflects that one wasn't provided
and your handling here would be appropriate for that.

> +
> +	saradc->regs = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(saradc->regs)) {
> +		ret = PTR_ERR(saradc->regs);
> +		return ret;

		return PTR_ERR(saradc->regs);
and drop the brackets.

> +	}
> +
> +	saradc->irq = platform_get_irq_optional(pdev, 0);
> +	if (saradc->irq >= 0) {
> +		init_completion(&saradc->completion);
> +		ret = devm_request_irq(&pdev->dev, saradc->irq,
> +				cv18xx_adc_interrupt_handler, 0,
> +				dev_name(&pdev->dev), saradc);

Where it isn't limited by line length, preferred style is to align to
just after the opening bracket. e.g.

		ret = devm_request_irq(&pdev->dev, saradc->irq,
				       cv18xx_adc_interrupt_handler, 0,
				       dev_name(&pdev->dev), saradc);

> +		if (ret)
> +			return ret;
> +
> +		writel(1, saradc->regs + CV18XX_ADC_INTR_EN_REG);
> +

Drop this blank line.

> +	}

One blank here is plenty.

> +
> +
> +	mutex_init(&saradc->lock);

Whilst mutex cleanup is of dubious benefit as only helpful if doing particularly forms
of mutex debugging and looking for use after free etc, we do finally have devm_mutex_init()
to make it easy so for new code I'm going to encourage it's use but not insist
on it yet...

	ret = devm_mutex_init(&saradc->lock);
	if (ret)
		return;

> +	platform_set_drvdata(pdev, indio_dev);
> +	writel(CV18XX_ADC_DEF_CYC_SETTINGS, saradc->regs + CV18XX_ADC_CYC_SET_REG);
> +	ret = devm_iio_device_register(&pdev->dev, indio_dev);
> +	if (ret)
> +		return ret;
> +
> +	return 0;

	return devm_iio_device_register().

> +}


  parent reply	other threads:[~2024-07-06 11:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-05 13:42 [PATCH v2 0/3] Add SARADC support on Sophgo SoC Thomas Bonnefille
2024-07-05 13:42 ` [PATCH v2 1/3] dt-bindings: iio: adc: sophgo,cv18xx-saradc.yaml: Add Sophgo SARADC binding documentation Thomas Bonnefille
2024-07-05 15:01   ` Conor Dooley
2024-07-05 15:24     ` Thomas Bonnefille
2024-07-06 12:42       ` Conor Dooley
2024-07-08  6:30         ` Miquel Raynal
2024-07-08  7:33           ` Krzysztof Kozlowski
2024-07-08 12:23             ` Miquel Raynal
2024-07-08 15:57               ` Jonathan Cameron
2024-07-09  7:27                 ` Miquel Raynal
2024-07-08 15:10         ` Thomas Bonnefille
2024-07-05 13:42 ` [PATCH v2 2/3] iio: adc: sophgo-saradc: Add driver for Sophgo SARADC Thomas Bonnefille
2024-07-06  5:16   ` kernel test robot
2024-07-06 10:58     ` Jonathan Cameron
2024-07-06 11:10   ` Jonathan Cameron [this message]
2024-07-05 13:42 ` [PATCH v2 3/3] riscv: dts: sophgo: Add SARADC configuration Thomas Bonnefille
2024-07-09  2:10 ` [PATCH v2 0/3] Add SARADC support on Sophgo SoC Chen Wang

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=20240706121004.37ee9fb5@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=inochiama@outlook.com \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=thomas.bonnefille@bootlin.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=unicorn_wang@outlook.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).