rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Benno Lossin <lossin@kernel.org>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	dri-devel@lists.freedesktop.org, dakr@kernel.org,
	acourbot@nvidia.com, Alistair Popple <apopple@nvidia.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
	bjorn3_gh@protonmail.com,
	Andreas Hindborg <a.hindborg@kernel.org>,
	Alice Ryhl <aliceryhl@google.com>,
	Trevor Gross <tmgross@umich.edu>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	John Hubbard <jhubbard@nvidia.com>, Timur Tabi <ttabi@nvidia.com>,
	joel@joelfernandes.org, Elle Rhumsaa <elle@weathered-steel.dev>,
	Yury Norov <yury.norov@gmail.com>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	nouveau@lists.freedesktop.org
Subject: Re: [PATCH v4 1/6] nova-core: bitfield: Move bitfield-specific code from register! into new macro
Date: Mon, 29 Sep 2025 15:45:53 -0400	[thread overview]
Message-ID: <467ce12e-ff42-4244-909a-9d40a3d35ceb@nvidia.com> (raw)
In-Reply-To: <2025092924-cork-mobilize-cfbf@gregkh>



On 9/29/2025 9:37 PM, Greg KH wrote:
> On Mon, Sep 29, 2025 at 03:26:57PM -0400, Joel Fernandes wrote:
>> 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.
> 
> Just don't go down the old path like drivers/net/fddi/skfp/h/supern_2.h
> does with it's definition of:

But this is not a comparable example though because in our macro we specify
individual bit numbers, not just bit width. So tx_length for example would
always start at the lower 2 bytes since we'd specify "tx_length 0:15" regardless
of whether those 2 bytes are higher in memory or lower in memory.  Whether it is
higher or lower depends on CPU endianness AFAICS, and if interacting with HW is
needed, the user of the macro would do endianness conversion. Maybe we should
add a comment about such conversion requirements?

Then there is the issue of the byte ordering within a multi-byte field. That
again follows CPU endianness, and we could add a comment for the benefit of
macro user.
> 
> 	union tx_descr {
> 		struct {
> 	#ifdef  LITTLE_ENDIAN
> 		unsigned int    tx_length:16 ;  /* frame length lower/upper byte */
> 		unsigned int    tx_res   :8 ;   /* reserved      (bit 16..23) */
> 		unsigned int    tx_xmtabt:1 ;   /* transmit abort */
> 		unsigned int    tx_nfcs  :1 ;   /* no frame check sequence */
> 		unsigned int    tx_xdone :1 ;   /* give up token */
> 		unsigned int    tx_rpxm  :2 ;   /* byte offset */
> 		unsigned int    tx_pat1  :2 ;   /* must be TXP1 */
> 		unsigned int    tx_more  :1 ;   /* more frame in chain */
> 	#else
> 		unsigned int    tx_more  :1 ;   /* more frame in chain */
> 		unsigned int    tx_pat1  :2 ;   /* must be TXP1 */
> 		unsigned int    tx_rpxm  :2 ;   /* byte offset */
> 		unsigned int    tx_xdone :1 ;   /* give up token */
> 		unsigned int    tx_nfcs  :1 ;   /* no frame check sequence */
> 		unsigned int    tx_xmtabt:1 ;   /* transmit abort */
> 		unsigned int    tx_res   :8 ;   /* reserved      (bit 16..23) */
> 		unsigned int    tx_length:16 ;  /* frame length lower/upper byte */
> 	#endif
> 		} t ;
> 		long    i ;
> 	} ;
> 

This is indeed yuck though but afaics not what hopefully we'd be doing ;-)

thanks,

 - Joel


  reply	other threads:[~2025-09-29 19:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-20 18:22 [PATCH v4 0/6] Introduce bitfield and move register macro to rust/kernel/ Joel Fernandes
2025-09-20 18:22 ` [PATCH v4 1/6] nova-core: bitfield: Move bitfield-specific code from register! into new macro Joel Fernandes
2025-09-21  9:36   ` Greg KH
2025-09-21  9:59     ` Miguel Ojeda
2025-09-21 11:23       ` Greg KH
2025-09-21 12:33     ` Benno Lossin
2025-09-21 12:45       ` Greg KH
2025-09-21 13:47         ` Danilo Krummrich
2025-09-23  6:38           ` Behme Dirk (XC-CP/ESD1)
2025-09-24 10:52           ` Greg KH
2025-09-24 11:28             ` Danilo Krummrich
2025-09-24 12:04               ` Greg KH
2025-09-24 14:38             ` Yury Norov
2025-09-24 15:53               ` Danilo Krummrich
2025-09-24 17:46               ` Joel Fernandes
2025-09-24 20:01                 ` Elle Rhumsaa
2025-09-25  7:05                   ` Joel Fernandes
2025-09-23 22:24         ` Joel Fernandes
2025-09-24 10:40           ` Greg KH
2025-09-29 19:26             ` Joel Fernandes
2025-09-29 19:37               ` Greg KH
2025-09-29 19:45                 ` Joel Fernandes [this message]
2025-09-29 20:25               ` Danilo Krummrich
2025-09-21 13:49     ` Danilo Krummrich
2025-09-29  6:16   ` Alexandre Courbot
2025-09-29 19:36     ` Joel Fernandes
2025-09-20 18:22 ` [PATCH v4 2/6] nova-core: bitfield: Add support for different storage widths Joel Fernandes
2025-09-29  6:22   ` Alexandre Courbot
2025-09-29 19:47     ` Joel Fernandes
2025-09-20 18:22 ` [PATCH v4 3/6] nova-core: bitfield: Add support for custom visiblity Joel Fernandes
2025-09-29  6:28   ` Alexandre Courbot
2025-09-29 20:20     ` Joel Fernandes
2025-09-20 18:22 ` [PATCH v4 4/6] rust: Move register and bitfield macros out of Nova Joel Fernandes
2025-09-29  6:30   ` Alexandre Courbot
2025-09-20 18:22 ` [PATCH v4 5/6] rust: Add KUNIT tests for bitfield Joel Fernandes
2025-09-20 18:22 ` [PATCH v4 6/6] rust: bitfield: Use 'as' operator for setter type conversion Joel Fernandes
2025-09-29  6:47   ` Alexandre Courbot
2025-09-29 20:32     ` Joel Fernandes
2025-09-29 13:59   ` Miguel Ojeda
2025-09-29 14:44     ` Alexandre Courbot
2025-09-29 15:17       ` Miguel Ojeda
2025-09-30 12:03       ` Joel Fernandes
2025-09-29 15:26     ` Yury Norov
2025-09-29 20:46     ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=467ce12e-ff42-4244-909a-9d40a3d35ceb@nvidia.com \
    --to=joelagnelf@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=elle@weathered-steel.dev \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).