linux-kernel - Re: [PATCH v2 2/2] iio: adc: Add ti-ads1018 driver

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] [day] [month] [year] [list]

Message-ID: <aSnx3zjBIbNvslba@smile.fi.intel.com>
Date: Fri, 28 Nov 2025 21:02:55 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Kurt Borja <kuurtb@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Tobias Sperling <tobias.sperling@...ting.com>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v2 2/2] iio: adc: Add ti-ads1018 driver

On Fri, Nov 28, 2025 at 12:38:44PM -0500, Kurt Borja wrote:
> On Fri Nov 28, 2025 at 4:54 AM -05, Andy Shevchenko wrote:
> > On Thu, Nov 27, 2025 at 10:37:11PM -0500, Kurt Borja wrote:


Please, remove context you are agree with, no need to keep long message
which is harder to parse for what has been asked, answered, or discussed.

That said, I assume non-commented remarks will be addressed in the next
version as suggested.

...

> >> +static unsigned long ads1018_calc_delay(struct ads1018 *ads1018)
> >> +{
> >> +	const struct ads1018_chip_info *chip_info = ads1018->chip_info;
> >> +	unsigned long mode = chip_info->num_data_rate_mode_to_hz - 1;
> >> +	int hz = chip_info->data_rate_mode_to_hz[mode];
> >
> > Can frequency be negative?
> 
> I hope not 0.0
> 
> I return data_rate_mode_to_hz[] values directly in __ads1018_read_raw(),
> which uses `int *`. That's why I chose int, but I can just make it
> unsigned if that's preferred.

Keep it unsigned wherever it's possible.

...

> > static void ads1018_set_trigger_enable(struct ads1018 *ads1018)
> > {
> > 	spi_bus_lock(ads1018->spi->controller);
> > 	ads1018_read_locked(ads1018, NULL, true);
> > 	enable_irq(ads1018->drdy_irq);
> > }
> >
> > static void ads1018_set_trigger_disable(struct ads1018 *ads1018)
> > {
> > 	disable_irq(ads1018->drdy_irq);
> > 	ads1018_read_locked(ads1018, NULL, false);
> > 	spi_bus_unlock(ads1018->spi->controller);
> > }
> >
> > Or if you make _read_locked() to return the data, just ignoring it as in
> >
> > 	ads1018_read_locked(ads1018, ...);
> 
> Sure, I like this.

I noticed that it may return also an error, with that in mind the NULL pointer
is the easiest way to go.

...

> >> +static const int ads1018_gain_table[][2] = {
> >> +	ADS1018_FSR_TO_SCALE(6144, 11),
> >
> > This won't (hmm... might not? see below for the details) work on 32-bit.
> >
> >> +	ADS1018_FSR_TO_SCALE(4096, 11),
> >> +	ADS1018_FSR_TO_SCALE(2048, 11),
> >> +	ADS1018_FSR_TO_SCALE(1024, 11),
> >> +	ADS1018_FSR_TO_SCALE(512, 11),
> >> +	ADS1018_FSR_TO_SCALE(256, 11),
> >> +};
> >> +
> >> +static const int ads1118_gain_table[][2] = {
> >> +	ADS1018_FSR_TO_SCALE(6144, 15),
> >
> > Ditto.
> >
> >> +	ADS1018_FSR_TO_SCALE(4096, 15),
> >> +	ADS1018_FSR_TO_SCALE(2048, 15),
> >> +	ADS1018_FSR_TO_SCALE(1024, 15),
> >> +	ADS1018_FSR_TO_SCALE(512, 15),
> >> +	ADS1018_FSR_TO_SCALE(256, 15),
> >> +};
> >
> > To address that you need to divide MICRO at least by 2
> > (note, by 2⁶ is also possible without loosing in precision).
> >
> > // Assuming that you want to keep the initialisers as is now:
> > #define ADS1018_FSR_TO_SCALE(_fsr, _res) \
> > 	{ 0, ((_fsr) * (MICRO >> 6)) / BIT((_res) - 6) }
> >
> > OTOH, these all are constants, so the clever compiler (even 32-bit compiler)
> > may do it for you and won't complain as there is no overflow in the result.
> >
> > TL;DR: Try to compile this with 32-bit compiler on 32-bit machine before
> > changing as suggested.
> 
> I didn't consider 32-bit here... I'll test it for v3!

Every time you have a division in the code with (potentially) bit numbers
in the numerator and/or denominator always think about 32-bit case.

...

> Ack, for everything else. Thank you, Andy!

Okay, I assumed correctly in the top, but again, please remove the unneeded
context when replying.

-- 
With Best Regards,
Andy Shevchenko