linux-kernel - Re: [PATCH v4 1/6] nova-core: bitfield: Move bitfield-specific code from register! into new macro

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: <76f87707-17d8-4cb0-8c81-e67ebf62984a@nvidia.com>
Date: Mon, 29 Sep 2025 15:26:57 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Benno Lossin <lossin@...nel.org>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 dakr@...nel.org, acourbot@...dia.com, Alistair Popple <apopple@...dia.com>,
 Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 bjorn3_gh@...tonmail.com, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 John Hubbard <jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 joel@...lfernandes.org, Elle Rhumsaa <elle@...thered-steel.dev>,
 Yury Norov <yury.norov@...il.com>,
 Daniel Almeida <daniel.almeida@...labora.com>, nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v4 1/6] nova-core: bitfield: Move bitfield-specific code
 from register! into new macro

On 9/24/2025 12:40 PM, Greg KH wrote:
> On Tue, Sep 23, 2025 at 06:24:34PM -0400, Joel Fernandes wrote:
[..]
> 
>> For the separate issue of enforcing endianness with respect to (across)
>> multiple fields, I agree with you that if the user's backend (the consumer of
>> the data) is not doing such conversion, say via regmap, then that becomes a
>> problem. But that problem is orthogonal/different and cannot be solved here.  
> 
> But that is exactly what these macros are being defined here for, so to
> ignore that is going to cause problems :)
> 

If needed, happy to add endianness support as needed by providing additional
options to the macro. Based on this thread, it sounds like we want see if that
is really needed here or can be solved elsewhere (?). The mental model I kind of
have is this macro should only be dealing with CPU native endianness, much like
bitfields in C deal with CPU endianness. Hmm.

Thanks.