[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DAUR75ROUY1Y.1GX6ALNM4FUAX@nvidia.com>
Date: Tue, 24 Jun 2025 21:14:24 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Danilo Krummrich" <dakr@...nel.org>, "Miguel Ojeda"
<miguel.ojeda.sandonis@...il.com>
Cc: "Stephen Rothwell" <sfr@...b.auug.org.au>, "Lyude Paul"
<lyude@...hat.com>, "Andreas Hindborg" <a.hindborg@...nel.org>, "FUJITA
Tomonori" <fujita.tomonori@...il.com>, "Miguel Ojeda" <ojeda@...nel.org>,
"Tamir Duberstein" <tamird@...il.com>, "Linux Kernel Mailing List"
<linux-kernel@...r.kernel.org>, "Linux Next Mailing List"
<linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the rust tree
On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
> On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
>> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>> >
>> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
>>
>> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
>>
>> > Presumably caused by commit
>> >
>> > b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
>>
>> The first error, yes -- the `register!` macro was changed to use
>> `u32::from()` to avoid an `as` cast in that commit, and while the cast
>> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
>> isn't`, so we would need to implement `From` explicitly -- Cc'ing
>> Danilo, Alexandre, Lyude.
>
> It's a bit annoying to implement From explicitly for all of them, but it seems
> to be the correct thing to do.
This might be something `FromPrimitive` will help with eventually, but
in the meantime I agree having explicit implementations is a bit
cumbersome.
What I don't understand is why these `as` are problematic - a type like
`FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
is the case for all such instances using the register!() macro.
>
> nova-next also contains a couple of cases where the introduction of
> `cast_lossless` causes warnings.
>
> I can implement the From traits and fix up the warnings caused by enabling
> `cast_lossless` in my tree with subsequent patches, such that we do not have to
> carry all this as merge resolution.
Let me know if you want me to take care of that.
Powered by blists - more mailing lists