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: <5b843df0-138e-4e2e-a70d-beb8a39ed85f@baylibre.com>
Date: Sun, 7 Dec 2025 11:12:51 -0600
From: David Lechner <dlechner@...libre.com>
To: Kurt Borja <kuurtb@...il.com>, Jonathan Cameron <jic23@...nel.org>
Cc: 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 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.