linux-kernel - Re: [PATCH] iio: temperature: maxim_thermocouple: use IIO_DECLARE_DMA_BUFFER_WITH

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] [day] [month] [year] [list]

Message-ID: <8b822cda-6bf8-41b1-bb08-f52e2f0b88f1@baylibre.com>
Date: Sun, 13 Jul 2025 11:26: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>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: temperature: maxim_thermocouple: use
 IIO_DECLARE_DMA_BUFFER_WITH_TS()

On 7/13/25 9:10 AM, Jonathan Cameron wrote:
> On Fri, 11 Jul 2025 13:38:17 -0500
> David Lechner <dlechner@...libre.com> wrote:
> 
>> On 7/11/25 12:50 PM, Andy Shevchenko wrote:
>>> On Fri, Jul 11, 2025 at 12:04:03PM -0500, David Lechner wrote:  
>>>> On 7/11/25 11:41 AM, Andy Shevchenko wrote:  
>>>>> On Fri, Jul 11, 2025 at 10:33:55AM -0500, David Lechner wrote:  
>>>
>>> ...
>>>   
>>>>>> +#include <asm/byteorder.h>  
>>>>>
>>>>> Hmm... I see nothing about this change in the commit message.  
>>>>
>>>> It is for __be16. I kind of assumed that would be obvious, but sure,
>>>> better to be explicit about it.  
>>>
>>> Isn't it in types.h?
>>>   
>>
>> No, only CPU-endian types are in types.h. The actual #define for
>>  __be16 is in include/uapi/linux/byteorder/big_endian.h. This is
>> included in one driver in staging, otherwise it is only included
>> in arch/*/include/uapi/asm/byteorder.h. And asm/byteorder.h is what
>> Jonathan used for similar in some of his recent IWYU patches as well,
>> so I assume that is the preferred way to do it.
>>
> Never trust me :)  I may have been after be16_to_cpu() or similar
> though rather than the type. Can't remember. When I get back to those
> I'll take a look at the logs.
> 
> 

Yes, you used asm/byteorder for le16_to_cpup() then I (incorrectly)
made the leap that e.g. __le16 would come from there as well.