Re: Looking for a solution for CPM FSL SPI driver that swaps 16 bits words

[Christophe Leroy <christophe.leroy@xxxxxxxxxx>]

Hi Mark,

Le 07/03/2023 à 23:16, Mark Brown a écrit :
> On Tue, Mar 07, 2023 at 09:40:09PM +0000, Christophe Leroy wrote:
>>>    * In-memory data values are always in native CPU byte order, translated
>>>    * from the wire byte order (big-endian except with SPI_LSB_FIRST).  So
>>>    * for example when bits_per_word is sixteen, buffers are 2N bytes long
>>>    * (@len = 2N) and hold N sixteen bit words in CPU byte order.
> 
>>> LSB_FIRST has only one in tree user other than spidev so I'd question
>>> how often it's correctly implemented.
> 
>> Well, ok, I have no problem with the wire byte order, only with how the
>> controller fetches the data from the DMA buffer. I'm not sure what I
>> write is clear, is it ?
> 
> You have a problem with the wire byte order not being what was
> requested - the data should always be big endian unless otherwise
> specified.
> 

Looking at another driver I'm even more puzzled. That's driver 
drivers/leds/leds-dac124s085.c

It also sets spi->bits_per_word = 16 , but is uses cpu_to_le16() to 
prepare that data. So this one should then work with any host 
endianness, but why the hell is it doing cpu_to_le16() if the data 
should be big endian ?

To be honnest, I'm really not sure anymore what is the way to go.

Christophe