Message-ID: <e05f7e9b-f3c1-4b66-993a-31d16e5147c2@baylibre.com>
Date: Mon, 25 Aug 2025 12:07:22 -0500
From: David Lechner <dlechner@...libre.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Yasin Lee <yasin.lee.x@...il.com>,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH] iio: proximity: hx9023s: fix scan_type endianness

On 7/23/25 10:56 AM, Jonathan Cameron wrote:
> On Wed, 23 Jul 2025 10:11:50 -0500
> David Lechner <dlechner@...libre.com> wrote:
> 
>> On 7/23/25 10:06 AM, Andy Shevchenko wrote:
>>> On Wed, Jul 23, 2025 at 09:57:58AM -0500, David Lechner wrote:  
>>>> On 7/23/25 9:37 AM, Andy Shevchenko wrote:  
>>>>> On Wed, Jul 23, 2025 at 09:29:37AM -0500, David Lechner wrote:  
>>>>>> On 7/23/25 9:13 AM, Andy Shevchenko wrote:  
>>>>>>> On Tue, Jul 22, 2025 at 06:08:37PM -0500, David Lechner wrote:  
>>>>>>>> On 7/22/25 6:07 PM, David Lechner wrote:  
>>>>>>>>> Change the scan_type endianness from IIO_BE to IIO_LE. This matches
>>>>>>>>> the call to cpu_to_le16() in hx9023s_trigger_handler() that formats
>>>>>>>>> the data before pushing it to the IIO buffer.  
>>>>>>>  
>>>>>>>> It is odd to have data already in CPU-endian and convert it to LE
>>>>>>>> before pushing to buffers. So I'm a bit tempted to do this instead
>>>>>>>> since it probably isn't likely anyone is using this on a big-endian
>>>>>>>> system:  
>>>>>>>
>>>>>>> I can say that first of all, we need to consult with the datasheet for the
>>>>>>> actual HW endianess. And second, I do not believe that CPU endianess may be
>>>>>>> used,   
>>>>>>
>>>>>> Why not? Lot's of IIO drivers use IIO_CPU in their scan buffers.
>>>>>>  
>>>>>>> I can't imagine when this (discrete?) component can be integrated in such
>>>>>>> a way. That said, I think your second approach even worse.  
>>>>>>
>>>>>> hx9023s_sample() is calling get_unaligned_le16() on all of the data
>>>>>> read over the bus, so in the driver, all data is stored CPU-endian
>>>>>> already rather than passing actual raw bus data to the buffer.  
>>>>>
>>>>> I see, now it makes a lot of sense. Thanks for clarifying this to me.
>>>>>  
>>>>>> So it seems a waste of CPU cycles to convert it back to little-endian
>>>>>> to push to the buffer only for consumers to have to convert it back
>>>>>> to CPU-endian again. But since most systems are little-endian already
>>>>>> this doesn't really matter since no actual conversion is done in this
>>>>>> case.  
>>>>>
>>>>> Right, but it's buggy on BE, isn't it?
>>>>>  
>>>>
>>>> Right now, the driver is buggy everywhere. The scan info says that the
>>>> scan data is BE, but in reality, it is LE (no matter the CPU-endianness).
>>>>
>>>> With the simple patch, it fixes the scan info to reflect reality that
>>>> the data is LE in the buffer. This works on BE systems. They just have
>>>> an extra conversion from BE to LE in the kernel when pushing to the
>>>> buffer and userspace would have to convert back to BE to do math on it.
>>>>
>>>> With the alternate patch you didn't like, the forced conversion to LE
>>>> when pushing to buffers is dropped, so nothing would change on LE
>>>> systems but BE systems wouldn't have the extra order swapping.  
>>>
>>> But do they need that? If you supply CPU order (and it is already in a such
>>> after get_unaligned_*() calls) then everything would be good, no?
>>>   
>>
>> It doesn't make sense to my why, but the existing code is changing
>> back to LE before pushing to buffers for some reason.
>>
>>
>> 	iio_for_each_active_channel(indio_dev, bit) {
>> 		index = indio_dev->channels[bit].channel;
>> 		data->buffer.channels[i++] = cpu_to_le16(data->ch_data[index].diff);
>> 	}
>>
>> 	iio_push_to_buffers_with_ts(indio_dev, &data->buffer,
>> 				    sizeof(data->buffer), pf->timestamp);
>>
>> I agree that it seems unnecessary which is why I suggested the
>> alternate patch to drop the cpu_to_le16() and just leave it
>> CPU-endian when pushing to the buffers.
>>
> 
> This one was seriously odd and went though a lot of discussions around
> endian conversions during review.  Definitely wait for Yasin to reply.
> 
> That's not to say I can recall how we ended up with the dance that
> you are seeing now (and I'm too far behind on reviews to get to digging
> through threads to refresh my memory).
> 
> Jonathan
> 
> 

I found the message you are likely referring to [1]. It explains why we
can't use the raw data directly. There is some processing of the values
that is required. However, it doesn't explain the choice to convert things
to little-endian after the processing. Given the patch snippet in the
linked message, I think the intention (albeit misguided - we should have
suggested to just leave things CPU-endian) was to change from big-endian
to little-endian everywhere, but changing the scan_type to match was
overlooked in later revisions.

Applying this patch seems like the simplest thing to do. Or, if we don't want
others copying this questionable code, we could consider the heavier-handed
alternative to keep things CPU-endian.

[1]: https://lore.kernel.org/linux-iio/SN7PR12MB810159A22C9814AA7FC1AB96A4CE2@SN7PR12MB8101.namprd12.prod.outlook.com/

Powered by blists - more mailing lists