mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: "Herve Codina (Schneider Electric)" <herve.codina@bootlin.com>
Cc: "Wolfram Sang" <wsa+renesas@sang-engineering.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>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	linux-iio@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Pascal Eberhard" <pascal.eberhard@se.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 2/4] iio: adc: Add support for the Renesas RZ/N1 ADC
Date: Wed, 15 Oct 2025 17:55:38 +0300	[thread overview]
Message-ID: <aO-16hC5r7-FB9Pw@smile.fi.intel.com> (raw)
In-Reply-To: <20251015142816.1274605-3-herve.codina@bootlin.com>

On Wed, Oct 15, 2025 at 04:28:14PM +0200, Herve Codina (Schneider Electric) wrote:

Thanks for the contribution, my comments below.

TL;DR: seems like somebody just submitted a driver without doing an internal
review with the kernel developers familiar with the upstream (and I believe
there are such in your company). This is not good. You, guys, should try your
best and not put a burden on the maintainer's/reviewers' shoulders.

> The Renesas RZ/N1 ADC controller is the ADC controller available in the
> Renesas RZ/N1 SoCs family. It can use up to two internal ACD cores (ADC1
> and ADC2) those internal cores are not directly accessed but are handled
> through ADC controller virtual channels.

...

> +#include <linux/kernel.h>

Definitely big no for this one.

> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/interrupt.h>
> +#include <linux/mutex.h>
> +#include <linux/completion.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/machine.h>
> +#include <linux/iio/driver.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/bits.h>

> +#include <linux/of.h>

And simple "no" to this one.

> +#include <linux/regulator/consumer.h>
> +#include <linux/pm_runtime.h>

In IIO we do
1) follow IWYU principle;
2) keep headers ordered (with possible grouping of iio/* ones or others if more
than one and specific to a domain);

...

> +#define RZN1_ADC_CONTROL_REG	0x2c
> +#define RZN1_ADC_CONTROL_ADC_BUSY	BIT(6)
> +#define RZN1_ADC_FORCE_REG		0x30
> +#define RZN1_ADC_SET_FORCE_REG		0x34
> +#define RZN1_ADC_CLEAR_FORCE_REG	0x38
> +#define RZN1_ADC_FORCE_VC(_n)		BIT(_n)

Please, make sure _REG definition values are on the column, same for bitfield
defs (some people like indent them slightly differently to the regs).

> +#define RZN1_ADC_CONFIG_REG	0x40
> +#define RZN1_ADC_CONFIG_ADC_POWER_DOWN	BIT(3)

...

> +#define RZN1_ADC_VC_REG(_n)	(0xc0 + 0x4 * (_n))

0x4 --> 4 as it's just a stride. Same for the rest of the similar cases.

...

> +struct rzn1_adc_core {
> +	int is_used;
> +	struct regulator *avdd;
> +	struct regulator *vref;

Possible waste of 4 bytes on some architectures. Please, run `pahole` and see
the opportunities to improve all data structure types in the driver.

> +};

...

> +static int rzn1_adc_core_power_on(struct rzn1_adc_core *adc_core)
> +{
> +	int ret;
> +
> +	if (!adc_core->is_used)
> +		return 0;
> +
> +	ret = regulator_enable(adc_core->avdd);
> +	if (ret)
> +		return ret;
> +
> +	ret = regulator_enable(adc_core->vref);
> +	if (ret) {
> +		regulator_disable(adc_core->avdd);
> +		return ret;
> +	}

Don't we have bulk API? Can't it be used here? Why?

> +	return 0;
> +}

...

> +static int rzn1_adc_core_get_regulators(struct rzn1_adc *rzn1_adc,
> +					struct rzn1_adc_core *adc_core,
> +					const char *avdd_name, const char *vref_name)
> +{
> +	struct device *dev = rzn1_adc->dev;
> +	int ret;
> +
> +	adc_core->avdd = devm_regulator_get_optional(dev, avdd_name);

	ret = PTR_ERR_OR_ZERO(...);

might simplify the below.

> +	if (IS_ERR(adc_core->avdd)) {
> +		ret = PTR_ERR(adc_core->avdd);
> +		if (ret != -ENODEV)
> +			return dev_err_probe(dev, ret,
> +					     "Failed to get '%s' regulator\n",
> +					     avdd_name);
> +		adc_core->avdd = NULL;
> +	}

Like
	if (ret == -ENODEV)
		...
	else if (ret)
		return dev_err_probe(...);

> +	adc_core->vref = devm_regulator_get_optional(dev, vref_name);
> +	if (IS_ERR(adc_core->vref)) {
> +		ret = PTR_ERR(adc_core->vref);
> +		if (ret != -ENODEV)
> +			return dev_err_probe(dev, ret,
> +					     "Failed to get '%s' regulator\n",
> +					     vref_name);
> +		adc_core->vref = NULL;
> +	}

Ditto. (However see above about bulk API)

I'm so much wondering when somebody provides a wrapper that _optional() for
regulator will be optional from device source code pattern so we won't see
anymore these checks for ENODEV (with chance > 0 of a mistake in some cases as
it's usually an unintuitive for use API if you need to test for the specific
error code).

> +	/*
> +	 * Both regulators (avdd and vref) need to be available to have the
> +	 * related adc_core used.
> +	 */
> +	adc_core->is_used = adc_core->vref && adc_core->avdd;
> +	return 0;
> +}

...

> +static int rzn1_adc_core_get_vref_mv(struct rzn1_adc_core *adc_core)
> +{
> +	int vref_uv;

_uV ?

> +
> +	if (!adc_core->vref)
> +		return -ENODEV;
> +
> +	vref_uv = regulator_get_voltage(adc_core->vref);
> +	if (vref_uv < 0)
> +		return vref_uv;
> +
> +	return vref_uv / 1000;

Hmm... (MICRO/MILLI) ?

> +}

...

> +static int rzn1_adc_power(struct rzn1_adc *rzn1_adc, bool power)
> +{
> +	u32 v;
> +
> +	writel(power ? 0 : RZN1_ADC_CONFIG_ADC_POWER_DOWN,
> +	       rzn1_adc->regs + RZN1_ADC_CONFIG_REG);
> +
> +	/*
> +	 * Wait for the ADC_BUSY to clear.

> +	 * On timeout, ret is -ETIMEDOUT, otherwise it will be 0.

Useless comment. It might be something else in some cases, we don't need to
explain this in every caller.

> +	 */
> +	return readl_poll_timeout_atomic(rzn1_adc->regs + RZN1_ADC_CONTROL_REG,
> +					 v, !(v & RZN1_ADC_CONTROL_ADC_BUSY),
> +					 0, 500);
> +}

...

> +static void rzn1_adc_vc_setup_conversion(struct rzn1_adc *rzn1_adc, u32 ch,
> +					 int adc1_ch, int adc2_ch)
> +{
> +	u32 vc = 0;
> +
> +	if (adc1_ch != -1)

The >= 0 is more robust in case the value gets an error pointer or -err code.

> +		vc |= RZN1_ADC_VC_ADC1_ENABLE | RZN1_ADC_VC_ADC1_CHANNEL_SEL(adc1_ch);
> +
> +	if (adc2_ch != -1)
> +		vc |= RZN1_ADC_VC_ADC2_ENABLE | RZN1_ADC_VC_ADC2_CHANNEL_SEL(adc2_ch);
> +
> +	writel(vc, rzn1_adc->regs + RZN1_ADC_VC_REG(ch));
> +}

> +static int rzn1_adc_vc_wait_conversion(struct rzn1_adc *rzn1_adc, u32 ch,
> +				       u32 *adc1_data, u32 *adc2_data)
> +{
> +	u32 data_reg;
> +	int ret;
> +	u32 v;
> +
> +	/*
> +	 * When a VC is selected, it needs 20 ADC clocks to perform the
> +	 * conversion.
> +	 *
> +	 * The worst case is when the 16 VCs need to perform a conversion and
> +	 * our VC is the lowest in term of priority.
> +	 *
> +	 * In that case, the conversion is performed in 16 * 20 ADC clocks.
> +	 *
> +	 * The ADC clock can be set from 4MHz to 20MHz. This leads to a worst
> +	 * case of  16 * 20 * 1/4Mhz = 80us.
> +	 *
> +	 * Round it up to 100us

Missing period.

> +	 */
> +
> +	/*
> +	 * Wait for the ADC_FORCE_VC(n) to clear.
> +	 *
> +	 * On timeout, ret is -ETIMEDOUT, otherwise it will be 0.
> +	 */
> +	ret = readl_poll_timeout_atomic(rzn1_adc->regs + RZN1_ADC_FORCE_REG,
> +					v, !(v & RZN1_ADC_FORCE_VC(ch)),
> +					0, 100);
> +	if (ret)
> +		return ret;
> +
> +	if (adc1_data) {
> +		data_reg = readl(rzn1_adc->regs + RZN1_ADC_ADC1_DATA_REG(ch));
> +		*adc1_data = RZN1_ADC_ADCX_GET_DATA(data_reg);
> +	}
> +
> +	if (adc2_data) {
> +		data_reg = readl(rzn1_adc->regs + RZN1_ADC_ADC2_DATA_REG(ch));
> +		*adc2_data = RZN1_ADC_ADCX_GET_DATA(data_reg);
> +	}
> +
> +	return 0;
> +}

I almost stopped here, see TL;DR above why.

...

> +static const struct of_device_id rzn1_adc_of_match[] = {
> +	{ .compatible = "renesas,rzn1-adc" },
> +	{ /* sentinel */ },

No comments, no commas in terminator entry. This is a common style in IIO.

> +};

> +

Unneeded blank line.

> +MODULE_DEVICE_TABLE(of, rzn1_adc_of_match);

...

> +static struct platform_driver rzn1_adc_driver = {
> +	.probe = rzn1_adc_probe,
> +	.remove = rzn1_adc_remove,
> +	.driver = {
> +		.name = "rzn1-adc",
> +		.of_match_table = of_match_ptr(rzn1_adc_of_match),

New code shouldn't use of_match_ptr().

> +		.pm = pm_ptr(&rzn1_adc_pm_ops),
> +	},
> +};

> +

Unneeded blank line.

> +module_platform_driver(rzn1_adc_driver);

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-10-18 17:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 14:28 [PATCH 0/4] " Herve Codina (Schneider Electric)
2025-10-15 14:28 ` [PATCH 1/4] dt-bindings: iio: adc: Add " Herve Codina (Schneider Electric)
2025-10-16 15:49   ` Krzysztof Kozlowski
2025-10-17  7:20     ` Herve Codina
2025-10-16 17:17   ` Wolfram Sang
2025-10-17  7:07     ` Herve Codina
2025-10-23  8:55       ` Herve Codina
2025-10-23  8:57         ` Wolfram Sang
2025-10-15 14:28 ` [PATCH 2/4] iio: adc: Add support for " Herve Codina (Schneider Electric)
2025-10-15 14:55   ` Andy Shevchenko [this message]
2025-10-15 15:21   ` Nuno Sá
2025-10-15 19:14     ` Herve Codina
2025-10-16  9:24       ` Nuno Sá
2025-10-16 14:02         ` Herve Codina
2025-10-16 15:26           ` Nuno Sá
2025-10-17  6:59             ` Herve Codina
2025-10-17  8:26               ` Nuno Sá
2025-10-17 15:43                 ` Herve Codina
2025-10-17 16:29                   ` Nuno Sá
2025-10-18 18:31                     ` Jonathan Cameron
2025-10-16 13:13   ` kernel test robot
2025-10-16 14:47   ` kernel test robot
2025-10-17  6:28   ` Wolfram Sang
2025-10-17  7:36     ` Herve Codina
2025-10-17  7:40       ` Geert Uytterhoeven
2025-10-17  7:59         ` Herve Codina
2025-10-17  9:03           ` Wolfram Sang
2025-10-17  9:11   ` Wolfram Sang
2025-10-17 15:00     ` Herve Codina
2025-10-17 15:14       ` Wolfram Sang
2025-10-18 19:10   ` Jonathan Cameron
2025-10-15 14:28 ` [PATCH 3/4] ARM: dts: renesas: r9a06g032: Add the ADC device Herve Codina (Schneider Electric)
2025-10-17  6:36   ` Wolfram Sang
2025-10-15 14:28 ` [PATCH 4/4] MAINTAINERS: Add the Renesas RZ/N1 ADC driver entry Herve Codina (Schneider Electric)
2025-10-17  6:30   ` Wolfram Sang

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=aO-16hC5r7-FB9Pw@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=geert+renesas@glider.be \
    --cc=herve.codina@bootlin.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nuno.sa@analog.com \
    --cc=pascal.eberhard@se.com \
    --cc=robh@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wsa+renesas@sang-engineering.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

all inboxes | Powered by JetHome®