linux-kernel - Re: [PATCH v6 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251207195613.0e222b3a@jic23-huawei>
Date: Sun, 7 Dec 2025 19:56:13 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Kurt Borja <kuurtb@...il.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Tobias
 Sperling <tobias.sperling@...ting.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 v6 2/2] iio: adc: Add ti-ads1018 driver

On Sun, 7 Dec 2025 11:12:51 -0600
David Lechner <dlechner@...libre.com> wrote:

> On 12/7/25 10:02 AM, Kurt Borja wrote:
> > On Sat Dec 6, 2025 at 3:07 PM -05, Jonathan Cameron wrote:  
> >> On Thu, 04 Dec 2025 13:01:28 -0500
> >> Kurt Borja <kuurtb@...il.com> wrote:
> >>  
> >>> Add ti-ads1018 driver for Texas Instruments ADS1018 and ADS1118 SPI
> >>> analog-to-digital converters.
> >>>
> >>> These chips' MOSI pin is shared with a data-ready interrupt. Defining
> >>> this interrupt in devicetree is optional, therefore we only create an
> >>> IIO trigger if one is found.
> >>>
> >>> Handling this interrupt requires some considerations. When enabling the
> >>> trigger the CS line is tied low (active), thus we need to hold
> >>> spi_bus_lock() too, to avoid state corruption. This is done inside the
> >>> set_trigger_state() callback, to let users use other triggers without
> >>> wasting a bus lock.
> >>>
> >>> Signed-off-by: Kurt Borja <kuurtb@...il.com>  
> > 
> > ...
> >   
> >>> +#define ADS1018_VOLT_CHAN(_index, _chan, _realbits) {				\
> >>> +	.type = IIO_VOLTAGE,							\
> >>> +	.channel = _chan,							\
> >>> +	.scan_index = _index,							\
> >>> +	.scan_type = {								\
> >>> +		.sign = 's',							\
> >>> +		.realbits = _realbits,						\
> >>> +		.storagebits = 16,						\
> >>> +		.shift = 16 - _realbits,					\
> >>> +		.endianness = IIO_BE,						\
> >>> +	},									\
> >>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |				\
> >>> +			      BIT(IIO_CHAN_INFO_SCALE) |			\
> >>> +			      BIT(IIO_CHAN_INFO_SAMP_FREQ),			\  
> >>
> >> What motivates per channel sampling frequency?
> >>
> >> Given you have to write it each time you configure I guess it doesn't matter much
> >> either way.  
> > 
> > I guess making it shared by all is simpler too, so I'll go with that.
> >   
> Just keep in mind that if there is ever some use case we don't know
> about that would require a different rate per channel, we can't change
> it without breaking usespace. Once the decision is made, we are
> locked in. Keeping it per-channel seems more future-proof to me.

Only way I can think of that might cause that to matter would be
if the complex dance to avoid the onehot buffer restriction is added.
Given you gave this response I went looking and that might make
sense as an enhancement as the SPI protocol would allow a crafted message
sequence to do this efficiently.  Extension of figure 15 where first message
sets config and after that they read out channel and set config for next one.

Given that is sane, I agree with you that we should probably keep these separate.
I doubt anyone will use different sampling frequencies even if possible but you
never know.

Jonathan

>