linux-kernel - Re: [PATCH 2/4] iio: adc: Add support for the Renesas RZ/N1 ADC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251017170054.7a7a6d5f@bootlin.com>
Date: Fri, 17 Oct 2025 17:00:54 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Jonathan Cameron <jic23@...nel.org>, David Lechner
 <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy
 Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Geert
 Uytterhoeven <geert+renesas@...der.be>, Magnus Damm
 <magnus.damm@...il.com>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown
 <broonie@...nel.org>, linux-iio@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Pascal Eberhard <pascal.eberhard@...com>,
 Miquel Raynal <miquel.raynal@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 2/4] iio: adc: Add support for the Renesas RZ/N1 ADC

Hi Wolfram,

On Fri, 17 Oct 2025 11:11:49 +0200
Wolfram Sang <wsa+renesas@...g-engineering.com> wrote:

> > +static int rzn1_adc_read_raw_ch(struct rzn1_adc *rzn1_adc, unsigned int chan, int *val)
> > +{
> > +	u32 *adc1_data, *adc2_data;
> > +	int adc1_ch, adc2_ch;
> > +	u32 adc_data;
> > +	int ret;
> > +
> > +	if (chan < 8) {
> > +		/* chan 0..7 used to get ADC1 ch 0..7 */
> > +		adc1_ch = chan;
> > +		adc1_data = &adc_data;
> > +		adc2_ch = -1;
> > +		adc2_data = NULL;
> > +	} else if (chan < 16) {
> > +		/* chan 8..15 used to get ADC2 ch 0..7 */
> > +		adc1_ch = -1;
> > +		adc1_data = NULL;
> > +		adc2_ch = chan - 8;
> > +		adc2_data = &adc_data;
> > +	} else {
> > +		return -EINVAL;
> > +	}  
> 
> How about putting part of the logic into the setup function? So, here
> only:
> 
> 	if (chan >= 16)
> 		return -EINVAL
> 
> > +
> > +	ret = pm_runtime_resume_and_get(rzn1_adc->dev);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	mutex_lock(&rzn1_adc->lock);
> > +
> > +	rzn1_adc_vc_setup_conversion(rzn1_adc, chan, adc1_ch, adc2_ch);  
> 
> 	rzn1_adc_vc_setup_conversion(rzn1_adc, chan);
> 
> And in that function:
> 
> > +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)
> > +		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));
> > +}  
> 
> 	if (ch < 8)
> 		vc |= RZN1_ADC_VC_ADC1_ENABLE | RZN1_ADC_VC_ADC1_CHANNEL_SEL(ch);
> 	else
> 		vc |= RZN1_ADC_VC_ADC2_ENABLE | RZN1_ADC_VC_ADC2_CHANNEL_SEL(ch - 8);
> 
> And a similar simplification for rzn1_adc_vc_wait_conversion().
> 
> Should work and the code is even more readable, I'd say. And has less
> lines.
> 

That was what I did on my first driver draft before sending this first
iteration. I moved to adc1 and adc2 channel numbers in parameters to avoid
adding this logic here.

I think it was better to decouple the IIO chan number from the adc core
channel used.

I don't know if it will be relevant but we can image a future improvement
where new IIO chans use both the ADC core 1 and 2. It could make sense.

IMHO, I think the solution you proposed is similar in term of complexity
to the RZN1_ADC_NO_CHANNEL approach. On my side, I would prefer the
RZN1_ADC_NO_CHANNEL approach to keep the decoupling between IIO chan and
ADC core chans.

That's said, I am still open to move in your direction if you still think
it is more relevant than the RZN1_ADC_NO_CHANNEL approach. Just tell me.

Best regards,
Hervé