linux-next: build failure in the final build

linux-next: build failure in the final build

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

Hi all,

After the final merge today's linux-next build (arm64 allyesconfig)
failed like this, the same issue will be present in mainline:

error: field `device` is never read
  --> /tmp/next/build/drivers/gpu/drm/tyr/driver.rs:37:5
   |
36 | pub(crate) struct TyrDriver {
   |                   --------- field in this struct
37 |     device: ARef<TyrDevice>,
   |     ^^^^^^
   |
   = note: `-D dead-code` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(dead_code)]`

error: fields `mali` and `sram` are never read
   --> /tmp/next/build/drivers/gpu/drm/tyr/driver.rs:196:5
    |
195 | struct Regulators {
    |        ---------- fields in this struct
196 |     mali: Regulator<regulator::Enabled>,
    |     ^^^^
197 |     sram: Regulator<regulator::Enabled>,
    |     ^^^^

error: aborting due to 2 previous errors

Caused by commit

   cf4fd52e32360 (rust: drm: Introduce the Tyr driver for Arm Mali GPUs)

I am continuing to mark the driver as BROKEN.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure in the final build

[Miguel Ojeda]

On Wed, Jan 21, 2026 at 6:14 PM Mark Brown <broonie@kernel.org> wrote:
>
> After the final merge today's linux-next build (arm64 allyesconfig)
> failed like this, the same issue will be present in mainline:

> Caused by commit
>
>    cf4fd52e32360 (rust: drm: Introduce the Tyr driver for Arm Mali GPUs)
>
> I am continuing to mark the driver as BROKEN.

Cc'ing Daniel as maintainer of Tyr and author of the commit -- somehow
he wasn't Cc'd?

Thanks Mark!

Cheers,
Miguel

Re: linux-next: build failure in the final build

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Wed, Jan 21, 2026 at 06:18:06PM +0100, Miguel Ojeda wrote:

> Cc'ing Daniel as maintainer of Tyr and author of the commit -- somehow
> he wasn't Cc'd?

Ah, sorry - I missed his signoff below the Link: trailer separate to the
rest of the author signoffs.  Copying the Cc list from the blamed commit
is a manual process for build failures, my mistake.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure in the final build

[Miguel Ojeda]

On Wed, Jan 21, 2026 at 6:25 PM Mark Brown <broonie@kernel.org> wrote:
>
> Ah, sorry - I missed his signoff below the Link: trailer separate to the
> rest of the author signoffs.  Copying the Cc list from the blamed commit
> is a manual process for build failures, my mistake.

No worries, happy to help! I indeed thought that part was probably
semi-automated.

Cheers,
Miguel

Re: linux-next: build failure in the final build

[Alice Ryhl]

On Wed, Jan 21, 2026 at 05:14:15PM +0000, Mark Brown wrote:
> Hi all,
> 
> After the final merge today's linux-next build (arm64 allyesconfig)
> failed like this, the same issue will be present in mainline:
> 
> error: field `device` is never read
>   --> /tmp/next/build/drivers/gpu/drm/tyr/driver.rs:37:5
>    |
> 36 | pub(crate) struct TyrDriver {
>    |                   --------- field in this struct
> 37 |     device: ARef<TyrDevice>,
>    |     ^^^^^^
>    |
>    = note: `-D dead-code` implied by `-D warnings`
>    = help: to override `-D warnings` add `#[allow(dead_code)]`
> 
> error: fields `mali` and `sram` are never read
>    --> /tmp/next/build/drivers/gpu/drm/tyr/driver.rs:196:5
>     |
> 195 | struct Regulators {
>     |        ---------- fields in this struct
> 196 |     mali: Regulator<regulator::Enabled>,
>     |     ^^^^
> 197 |     sram: Regulator<regulator::Enabled>,
>     |     ^^^^
> 
> error: aborting due to 2 previous errors
> 
> Caused by commit
> 
>    cf4fd52e32360 (rust: drm: Introduce the Tyr driver for Arm Mali GPUs)
> 
> I am continuing to mark the driver as BROKEN.

Hrm I saw you had this last time too. I'm not sure how you're triggering
it - I haven't run into it myself and I do enable warnings. But I'll try
to repro and fix it.

Note that for this kind of thing you can add `#![allow(warnings)]` to
the top of a file to silence warnings.

Alice

Re: linux-next: build failure in the final build

[Miguel Ojeda]

On Wed, Jan 21, 2026 at 8:14 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> Hrm I saw you had this last time too. I'm not sure how you're triggering
> it - I haven't run into it myself and I do enable warnings. But I'll try
> to repro and fix it.
>
> Note that for this kind of thing you can add `#![allow(warnings)]` to
> the top of a file to silence warnings.

Mark: we are in a call right now and Danilo asked about this -- I have
a similar issue with CI with `bounded.rs` in 1.80.0, so Danilo tested
1.80.0 and 1.80.1 and indeed 1.80.0 is broken.

We are upping the minimum to 1.85.0 soon, so it is not a big deal.

Could you please upgrade to Rust 1.80.1 at least for linux-next runs?
Where are you taking the toolchain from? i.e. I would expect a distro
to provide the fixed .1

We hope that helps!

Cheers,
Miguel

Re: linux-next: build failure in the final build

[Deborah Brouwer]

On Wed, Jan 21, 2026 at 07:14:38PM +0000, Alice Ryhl wrote:
> On Wed, Jan 21, 2026 at 05:14:15PM +0000, Mark Brown wrote:
> > Hi all,
> > 
> > After the final merge today's linux-next build (arm64 allyesconfig)
> > failed like this, the same issue will be present in mainline:
> > 
> > error: field `device` is never read
> >   --> /tmp/next/build/drivers/gpu/drm/tyr/driver.rs:37:5
> >    |
> > 36 | pub(crate) struct TyrDriver {
> >    |                   --------- field in this struct
> > 37 |     device: ARef<TyrDevice>,
> >    |     ^^^^^^
> >    |
> >    = note: `-D dead-code` implied by `-D warnings`
> >    = help: to override `-D warnings` add `#[allow(dead_code)]`
> > 
> > error: fields `mali` and `sram` are never read
> >    --> /tmp/next/build/drivers/gpu/drm/tyr/driver.rs:196:5
> >     |
> > 195 | struct Regulators {
> >     |        ---------- fields in this struct
> > 196 |     mali: Regulator<regulator::Enabled>,
> >     |     ^^^^
> > 197 |     sram: Regulator<regulator::Enabled>,
> >     |     ^^^^
> > 
> > error: aborting due to 2 previous errors
> > 
> > Caused by commit
> > 
> >    cf4fd52e32360 (rust: drm: Introduce the Tyr driver for Arm Mali GPUs)
> > 
> > I am continuing to mark the driver as BROKEN.
> 
> Hrm I saw you had this last time too. I'm not sure how you're triggering
> it - I haven't run into it myself and I do enable warnings. But I'll try
> to repro and fix it.

Although I hadn't seen this error before I was able to reproduce it
today on linux-next/master so I don't know if it's too late, but here is
a quick fix.

https://lore.kernel.org/rust-for-linux/20260122003746.405370-1-deborah.brouwer@collabora.com/

> 
> Note that for this kind of thing you can add `#![allow(warnings)]` to
> the top of a file to silence warnings.
> 
> Alice

Re: linux-next: build failure in the final build

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On Wed, Jan 21, 2026 at 07:14:38PM +0000, Alice Ryhl wrote:

> Note that for this kind of thing you can add `#![allow(warnings)]` to
> the top of a file to silence warnings.

That's not really the sort of thing we apply to -next usually.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure in the final build

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Wed, Jan 21, 2026 at 08:24:07PM +0100, Miguel Ojeda wrote:
> On Wed, Jan 21, 2026 at 8:14 PM Alice Ryhl <aliceryhl@google.com> wrote:

> > Note that for this kind of thing you can add `#![allow(warnings)]` to
> > the top of a file to silence warnings.

> Mark: we are in a call right now and Danilo asked about this -- I have
> a similar issue with CI with `bounded.rs` in 1.80.0, so Danilo tested
> 1.80.0 and 1.80.1 and indeed 1.80.0 is broken.

> We are upping the minimum to 1.85.0 soon, so it is not a big deal.

> Could you please upgrade to Rust 1.80.1 at least for linux-next runs?
> Where are you taking the toolchain from? i.e. I would expect a distro
> to provide the fixed .1

I've just got the default toolchain in Debian stable which appears to be
1.85.0.

ii  rustc                                 1.85.0+dfsg3-1                       arm64        Rust systems programming language

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]