[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6322f90-08bd-4e86-8dad-2ddbd7e5cece@nvidia.com>
Date: Tue, 18 Feb 2025 19:24:53 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>, Timur Tabi <ttabi@...dia.com>,
"daniel.almeida@...labora.com" <daniel.almeida@...labora.com>
CC: "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
"dakr@...nel.org" <dakr@...nel.org>, "airlied@...il.com" <airlied@...il.com>,
Ben Skeggs <bskeggs@...dia.com>
Subject: Re: [PATCH RFC 1/3] rust: add useful ops for u64
On 2/18/25 5:21 PM, Alexandre Courbot wrote:
> On Wed Feb 19, 2025 at 5:51 AM JST, Timur Tabi wrote:
>> On Tue, 2025-02-18 at 22:16 +0900, Alexandre Courbot wrote:
...
> More likely this would be something like:
>
> let SplitU64 { high: some_u32, .. } = some_u64;
>
> Which is still a bit verbose, but a single-liner.
>
> Actually. How about adding methods to this trait that return either
> component?
>
> let some_u32 = some_u64.high_half();
> let another_u32 = some_u64.low_half();
>
> These should be used most of the times, and using destructuring/tuple
> would only be useful for a few select cases.
I think I like this approach best so far, because that is actually how
drivers tend to use these values: one or the other 32 bits at a time.
Registers are often grouped into 32-bit named registers, and driver code
wants to refer to them one at a time (before breaking some of them down
into smaller named fields)>
The .high_half() and .low_half() approach matches that very closely.
And it's simpler to read than the SplitU64 API, without losing anything
we need, right?
thanks,
--
John Hubbard
Powered by blists - more mailing lists