Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Petar Stepanovic <pstepanovic@axiado.com>
Cc: "Akhila Kavi" <akavi@axiado.com>,
	"Prasad Bolisetty" <pbolisetty@axiado.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Harshit Shah" <hshah@axiado.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] iio: adc: add Axiado SARADC driver
Date: Fri, 5 Jun 2026 21:26:33 +0300	[thread overview]
Message-ID: <aiMU2bOFgKT9NrNQ@ashevche-desk.local> (raw)
In-Reply-To: <20260528-axiado-ax3000-ax3005-saradc-v1-2-345dd5f6608a@axiado.com>

On Thu, May 28, 2026 at 01:10:24AM -0700, Petar Stepanovic wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
> 
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.

(I'll try to not duplicate what Joshua noticed already.)

...

> +config AXIADO_SARADC
> +	tristate "Axiado SARADC driver"
> +	depends on ARCH_AXIADO || COMPILE_TEST

> +	depends on OF

No, in IIO we want a good justification on non-agnostic requirements.
Why can't this device driver be agnostic?

...


> +#include <linux/bitfield.h>

+ bits.h

> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/iio/iio.h>
> +#include <linux/io.h>

> +#include <linux/kernel.h>

No driver should have this header to be included.
Rare and well justified exceptions are possible
(and no, not in this case).

> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>

...

> +struct axiado_saradc {
> +	void __iomem *regs;
> +	struct clk *clk;
> +	unsigned long clk_rate;

> +	int vref_uv;

_uV (yes, capital letter as per SI).

> +	struct mutex lock; /* Serializes ADC conversions. */
> +};

...

> +static int axiado_saradc_conversion(struct axiado_saradc *info,
> +				    struct iio_chan_spec const *chan, int *val)
> +{
> +	unsigned long usecs;

Missing blank line here.

> +	/* Select the channel to be used and trigger conversion */

> +	iowrite32(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
> +		  info->regs + AX_SARADC_MANUAL_CTRL);

Why not writel()?

> +
> +	/* Hardware requires 13 conversion cycles at clk_rate */
> +	usecs = DIV_ROUND_UP(AX_SARADC_CONV_CYCLES * 1000000, info->clk_rate);

USe USEC_PER_SEC from time.h.

> +	usleep_range(usecs, usecs + 10);
> +
> +	*val = ioread32(info->regs + AX_SARADC_DOUT) &
> +	       GENMASK(AX_RESOLUTION_BITS - 1, 0);
> +
> +	/* Stop manual conversion */
> +	iowrite32(0, info->regs + AX_SARADC_MANUAL_CTRL);
> +	return 0;
> +}

...

> +static int axiado_saradc_probe(struct platform_device *pdev)
> +{
> +	struct axiado_saradc *info;
> +	const struct axiado_saradc_soc_data *soc_data;
> +	struct iio_dev *indio_dev;
> +	int ret;
> +	u32 reg;
> +
> +	indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	info = iio_priv(indio_dev);
> +
> +	info->regs = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(info->regs))
> +		return PTR_ERR(info->regs);
> +
> +	info->clk = devm_clk_get_enabled(&pdev->dev, NULL);

Why no name? It will make harder for the next generations of HW in case they
want more than one clock to be used.

> +	if (IS_ERR(info->clk))
> +		return PTR_ERR(info->clk);
> +
> +	info->clk_rate = clk_get_rate(info->clk);
> +	if (!info->clk_rate)
> +		return dev_err_probe(&pdev->dev, -EINVAL,
> +				     "invalid clock rate\n");

> +	info->vref_uv = devm_regulator_get_enable_read_voltage(&pdev->dev,
> +							       "vref");

Having

	struct device *dev = &pdev->dev;

will make the code shorter and easier to read.

> +	if (info->vref_uv < 0)
> +		return dev_err_probe(&pdev->dev, info->vref_uv,
> +				     "failed to get vref voltage\n");
> +
> +	soc_data = device_get_match_data(&pdev->dev);
> +	if (!soc_data)
> +		return dev_err_probe(&pdev->dev, -EINVAL,
> +				     "failed to get match data\n");
> +
> +	mutex_init(&info->lock);



> +	reg = FIELD_PREP(AX_SARADC_CH_EN_MASK,
> +			 GENMASK(soc_data->num_channels - 1, 0)) |
> +	      AX_SARADC_SAMPLE_16 | AX_SARADC_MODE | AX_SARADC_ENABLE;

FIELD_PREP_CONST() ?

> +	iowrite32(AX_SARADC_PD, info->regs + AX_SARADC_GLOBAL_CTRL);
> +	iowrite32(reg, info->regs + AX_SARADC_GLOBAL_CTRL);
> +
> +	indio_dev->name = dev_name(&pdev->dev);
> +	indio_dev->dev.parent = &pdev->dev;
> +	indio_dev->info = &axiado_saradc_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = axiado_saradc_iio_channels;
> +	indio_dev->num_channels = soc_data->num_channels;
> +
> +	ret = devm_iio_device_register(&pdev->dev, indio_dev);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "failed to register IIO device\n");
> +
> +	return 0;
> +}

...

> +static const struct of_device_id axiado_saradc_match[] = {
> +	{
> +		.compatible = "axiado,ax3000-saradc",
> +		.data = &ax3000_saradc_data,
> +	},
> +	{
> +		.compatible = "axiado,ax3005-saradc",
> +		.data = &ax3005_saradc_data,
> +	},
> +	{},

No comma for the terminator entry.

> +};

...

> +static struct platform_driver axiado_saradc_driver = {
> +	.driver = {
> +		.name = KBUILD_MODNAME,

We want to have these kind of strings to be fixed.

> +		.of_match_table = axiado_saradc_match,
> +	},
> +	.probe = axiado_saradc_probe,
> +};

> +

Unnecessary blank line.

> +module_platform_driver(axiado_saradc_driver);

-- 
With Best Regards,
Andy Shevchenko




  parent reply	other threads:[~2026-06-05 18:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28  8:10 [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add Axiado SARADC driver Petar Stepanovic
2026-05-28  8:10 ` [PATCH 1/3] dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC Petar Stepanovic
2026-05-28  9:20   ` Jonathan Cameron
2026-05-28 16:58   ` Conor Dooley
2026-05-28  8:10 ` [PATCH 2/3] iio: adc: add Axiado SARADC driver Petar Stepanovic
2026-05-28  9:02   ` Joshua Crofts
2026-05-28  9:44     ` Jonathan Cameron
2026-06-02 10:27       ` Petar Stepanovic
2026-06-05 18:26   ` Andy Shevchenko [this message]
2026-06-09  9:09     ` Petar Stepanovic
2026-06-09 13:26       ` Andy Shevchenko
2026-05-28  8:10 ` [PATCH 3/3] MAINTAINERS: add Axiado SARADC driver entry Petar Stepanovic
2026-05-28  8:29   ` Joshua Crofts
2026-05-28  9:17 ` [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add Axiado SARADC driver Jonathan Cameron
2026-06-03 14:19 ` Andy Shevchenko
2026-06-05 18:16 ` Andy Shevchenko

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=aiMU2bOFgKT9NrNQ@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=akavi@axiado.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=hshah@axiado.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=pbolisetty@axiado.com \
    --cc=pstepanovic@axiado.com \
    --cc=robh@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