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@xxxxxxxxxx> > > --- > > 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.
