From: Danilo Krummrich <dakr@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Alexandre Courbot <acourbot@nvidia.com>,
Lyude Paul <lyude@redhat.com>,
Andreas Hindborg <a.hindborg@kernel.org>,
FUJITA Tomonori <fujita.tomonori@gmail.com>,
Miguel Ojeda <ojeda@kernel.org>,
Tamir Duberstein <tamird@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the rust tree
Date: Tue, 24 Jun 2025 14:00:31 +0200 [thread overview]
Message-ID: <aFqTX2oDzacpDpif@pollux> (raw)
In-Reply-To: <CANiq72=nLeuw030T16-vDZT4A_gNyPm7WuXoK_3nFo0h0-eKJQ@mail.gmail.com>
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@canb.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.
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.
- Danilo
next prev parent reply other threads:[~2025-06-24 12:00 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 7:31 linux-next: build failure after merge of the rust tree Stephen Rothwell
2025-06-24 10:31 ` Miguel Ojeda
2025-06-24 11:12 ` Danilo Krummrich
2025-06-24 12:29 ` Miguel Ojeda
2025-06-24 12:00 ` Danilo Krummrich [this message]
2025-06-24 12:14 ` Alexandre Courbot
2025-06-24 12:16 ` Tamir Duberstein
2025-06-24 12:24 ` Alexandre Courbot
2025-06-24 12:29 ` Tamir Duberstein
2025-06-24 12:25 ` Miguel Ojeda
-- strict thread matches above, loose matches on Subject: below --
2025-11-17 8:04 Stephen Rothwell
2025-11-17 11:19 ` Alexandre Courbot
2025-11-17 14:51 ` Alice Ryhl
2025-11-17 15:37 ` Tamir Duberstein
2025-11-17 16:11 ` Alice Ryhl
2025-05-27 9:42 Stephen Rothwell
2025-05-27 10:03 ` Miguel Ojeda
2025-05-12 9:40 Stephen Rothwell
2025-05-12 11:52 ` Miguel Ojeda
2025-03-24 10:57 Stephen Rothwell
2025-03-24 11:06 ` Stephen Rothwell
2025-03-24 11:59 ` Danilo Krummrich
2025-03-24 13:29 ` Greg KH
2025-03-24 13:43 ` Danilo Krummrich
2025-03-24 13:52 ` Greg KH
2025-03-24 15:18 ` Miguel Ojeda
2025-03-24 15:27 ` Danilo Krummrich
2025-03-24 15:40 ` Miguel Ojeda
2025-03-17 10:57 Stephen Rothwell
2025-03-17 22:35 ` Miguel Ojeda
2025-03-17 23:35 ` Stephen Rothwell
2025-03-18 11:37 ` Stephen Rothwell
2025-03-18 23:47 ` Miguel Ojeda
2025-03-19 9:06 ` Stephen Rothwell
2025-03-19 9:18 ` Miguel Ojeda
2025-01-10 5:28 Stephen Rothwell
2025-01-10 9:28 ` Alice Ryhl
2025-01-10 9:34 ` Greg Kroah-Hartman
2025-01-10 9:41 ` Alice Ryhl
2025-01-10 10:07 ` Alice Ryhl
2025-01-10 10:08 ` Miguel Ojeda
2025-01-10 10:16 ` Miguel Ojeda
2025-01-10 10:38 ` Miguel Ojeda
2024-12-16 5:25 Stephen Rothwell
2024-12-16 10:31 ` Miguel Ojeda
2024-12-16 10:59 ` Jocelyn Falempe
2024-12-16 16:24 ` Miguel Ojeda
2024-12-16 19:46 ` Jocelyn Falempe
2024-11-11 6:58 Stephen Rothwell
2024-11-11 8:16 ` Miguel Ojeda
2024-11-11 8:28 ` Miguel Ojeda
2024-11-11 14:15 ` Gary Guo
2024-11-11 23:08 ` Miguel Ojeda
2024-11-11 23:58 ` Miguel Ojeda
2024-11-12 1:29 ` Stephen Rothwell
2024-11-12 6:30 ` Stephen Rothwell
2024-11-12 8:50 ` Miguel Ojeda
2021-09-28 4:09 Stephen Rothwell
2021-09-28 4:18 ` Gary Guo
2021-09-28 5:52 ` Stephen Rothwell
2021-09-28 23:37 ` Stephen Rothwell
2021-09-29 17:13 ` Masahiro Yamada
2021-09-29 17:25 ` Miguel Ojeda
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=aFqTX2oDzacpDpif@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=fujita.tomonori@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ojeda@kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=tamird@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