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: <Z92480lC8WdgyuiT@debian-BULLSEYE-live-builder-AMD64>
Date: Fri, 21 Mar 2025 16:07:31 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	jic23@...nel.org, lars@...afoo.de, Michael.Hennerich@...log.com,
	corbet@....net
Subject: Re: [PATCH v2 1/5] iio: adc: ad400: Set transfer bits_per_word to
 have data in CPU endianness

On 03/20, David Lechner wrote:
> On 3/19/25 9:57 AM, Marcelo Schmitt wrote:
> > When SPI `bits_per_word` is not set, SPI transfers default 8-bit word size
> > and ADC data gets stored in big-endian format in memory. Because of that,
> > the IIO driver requests ADC data to be rearranged from BE to CPU
> > endianness. However, with `bits_per_word` set to the number of ADC
> > precision bits, transfers use larger word sizes that get stored in
> > 'in-memory wordsizes' and can be read in CPU endianness.
> > 
> > Use proper `bits_per_word` size for SPI transfers thus saving the driver
> > from requesting endianness conversions. With that, shifting the buffer
> > data is also no longer needed. This change has no impact on IIO device
> > functionality.
> > 
> > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@...log.com>
> > ---
> 
> This is a breaking change. Some SPI controllers, like RPi can only do 8-bit
> transfers, so this driver would stop working on those platforms. Also, if
> anyone made software already that depended on the big-endian ordering without
> checking the scan_type attribute, it would break that software.

Hmm, if user space software doesn't check
deviceX/scan_elements/in_<channel_type>_type, nor
deviceX/bufferY/in_<channel_type>Y_type, then I'd say that's already
somewhat broken since at least buffer scan_element type attributes are documented
https://web.git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio?h=testing#n1470.

Anyway, this patch it indeed broke RPi support so I'll revert buffer endianness
and SPI transfer bits_per_word configurations the way it was in v1.

Adding possible failure due to controller not supporting specific bits_per_word
size to my list of peculiarities related to that field.

> 
> I would leave this as-is (drop this patch) and just make it:
> 
> 	.endianness = _offl ? IIO_CPU : IIO_BE,
> 
> in the next patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ