linux-kernel - Re: [PATCH v8 8/8] iio: adc: ad4030: Support common-mode channels with SPI offloading

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: <aYn4Xxj9TIXvYn7z@debian-BULLSEYE-live-builder-AMD64>
Date: Mon, 9 Feb 2026 12:08:15 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, jic23@...nel.org,
	michael.hennerich@...log.com, nuno.sa@...log.com,
	eblanc@...libre.com, dlechner@...libre.com, andy@...nel.org,
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	corbet@....net
Subject: Re: [PATCH v8 8/8] iio: adc: ad4030: Support common-mode channels
 with SPI offloading

On 02/08, Andy Shevchenko wrote:
> On Fri, Feb 06, 2026 at 04:02:42PM -0300, Marcelo Schmitt wrote:
> > AD4030 and similar devices can read common-mode voltage together with
> > ADC sample data. When enabled, common-mode voltage data is provided in a
> > separate IIO channel since it measures something other than the primary
> > ADC input signal and requires separate scaling to convert to voltage
> > units. The initial SPI offload support patch for AD4030 only provided
> > differential channels. Now, extend the AD4030 driver to also provide
> > common-mode IIO channels when setup with SPI offloading capability.
> 
> ...
> 
> > -#define AD4030_CHAN_CMO(_idx, _ch)  {					\
> > +#define __AD4030_CHAN_CMO(_idx, _ch, _offload)  {			\
> >  	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |			\
> >  		BIT(IIO_CHAN_INFO_SCALE),				\
> >  	.type = IIO_VOLTAGE,						\
> 
> >  	.scan_index = (_idx),						\
> >  	.scan_type = {							\
> >  		.sign = 'u',						\
> > -		.storagebits = 8,					\
> > +		.storagebits = (_offload ? 32 : 8),			\
> >  		.realbits = 8,						\
> > -		.endianness = IIO_BE,					\
> > +		.endianness = (_offload ? IIO_CPU : IIO_BE),		\
> 
> Hmm... This is interesting. Does it mean it's designed like this for any
> offloaded SPI case? Wouldn't be better to follow the same endianess in both?

Yes, as far as I'm aware of, the only SPI controller supporting offloading is
SPI Engine. And SPI Engine offloading pushes data to DMA in CPU endianness.
It would be easier to deal with only one endianness (BE in this case since the
device pushes out data in BE). But BE is currently not an oppion for offloaded
transfers. Making it IIO_CPU for all cases/setups would make it unsuable in
some setups that don't have SPI offload (e.g. raspberry pi only supports 8
bits_per_word would push data in BE to IIO buffers). Ideally, we would check
what are the endiannesses the controller supports for offload tranfers but there
is no offload provider other than SPI Engine so driver have been having it like
that so far.

> 
> >  	},								\
> >  }
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>