linux-kernel - Re: [PATCH] iio: proximity: hx9023s: fix scan

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: <7ca7e0b9-a77d-4de8-92b1-fea3250e8155@baylibre.com>
Date: Wed, 23 Jul 2025 09:57:58 -0500
From: David Lechner <dlechner@...libre.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Jonathan Cameron <jic23@...nel.org>, 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 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.