[PATCH] drm/tyr: suppress unread field warnings

[PATCH] drm/tyr: suppress unread field warnings

[Deborah Brouwer]

Currently these warnings, as errors, are preventing Tyr driver
from building:

error: field `device` is never read
  --> 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
   --> 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

Suppress these errors so that the Tyr driver will build.

Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
---
 drivers/gpu/drm/tyr/driver.rs | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
index 2a45d0288825..04c865cb4397 100644
--- a/drivers/gpu/drm/tyr/driver.rs
+++ b/drivers/gpu/drm/tyr/driver.rs
@@ -34,6 +34,7 @@
 
 #[pin_data(PinnedDrop)]
 pub(crate) struct TyrDriver {
+    #[allow(dead_code)]
     device: ARef<TyrDevice>,
 }
 
@@ -193,6 +194,8 @@ struct Clocks {
 
 #[pin_data]
 struct Regulators {
+    #[allow(dead_code)]
     mali: Regulator<regulator::Enabled>,
+    #[allow(dead_code)]
     sram: Regulator<regulator::Enabled>,
 }
-- 
2.52.0

Re: [PATCH] drm/tyr: suppress unread field warnings

[Miguel Ojeda]

On Thu, Jan 22, 2026 at 1:38 AM Deborah Brouwer
<deborah.brouwer@collabora.com> wrote:
>
> Currently these warnings, as errors, are preventing Tyr driver
> from building:

From what I understand, this is only reproducible with Rust 1.80.0
(unsupported upstream), and was fixed in Rust 1.80.1. Did you
reproduce it elsewhere? I asked Mark where his toolchain comes to see
what could be done there (e.g. in his distribution).

If it is just in Rust 1.80.0, and if a distribution still uses that
one, and for some reason they don't want to use/backport the fix in
1.80.1, then we could consider something more global, i.e. ignoring
that lint altogether for that version, since it also fails for another
trait in `bounded.rs` (that is why I knew about this).

(By the way, in any case, we would need a proper explanation of this
full context in the commit message.)

Thanks!

Cheers,
Miguel

Re: [PATCH] drm/tyr: suppress unread field warnings

[Deborah Brouwer]

On Thu, Jan 22, 2026 at 01:58:40AM +0100, Miguel Ojeda wrote:
> On Thu, Jan 22, 2026 at 1:38 AM Deborah Brouwer
> <deborah.brouwer@collabora.com> wrote:
> >
> > Currently these warnings, as errors, are preventing Tyr driver
> > from building:
> 
> From what I understand, this is only reproducible with Rust 1.80.0
> (unsupported upstream), and was fixed in Rust 1.80.1. Did you
> reproduce it elsewhere? I asked Mark where his toolchain comes to see
> what could be done there (e.g. in his distribution).

Yes, I have the error with 1.91.0
rustc --version --verbose
rustc 1.91.0 (f8297e351 2025-10-28)
binary: rustc
commit-hash: f8297e351a40c1439a467bbbb6879088047f50b3
commit-date: 2025-10-28
host: x86_64-unknown-linux-gnu
release: 1.91.0
LLVM version: 21.1.2

bindgen --version
bindgen 0.72.1

> 
> If it is just in Rust 1.80.0, and if a distribution still uses that
> one, and for some reason they don't want to use/backport the fix in
> 1.80.1, then we could consider something more global, i.e. ignoring
> that lint altogether for that version, since it also fails for another
> trait in `bounded.rs` (that is why I knew about this).
> 
> (By the way, in any case, we would need a proper explanation of this
> full context in the commit message.)
> 
> Thanks!
> 
> Cheers,
> Miguel

Re: [PATCH] drm/tyr: suppress unread field warnings

[Mark Brown]

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

On Thu, Jan 22, 2026 at 01:58:40AM +0100, Miguel Ojeda wrote:

> From what I understand, this is only reproducible with Rust 1.80.0
> (unsupported upstream), and was fixed in Rust 1.80.1. Did you
> reproduce it elsewhere? I asked Mark where his toolchain comes to see
> what could be done there (e.g. in his distribution).
> 
> If it is just in Rust 1.80.0, and if a distribution still uses that
> one, and for some reason they don't want to use/backport the fix in
> 1.80.1, then we could consider something more global, i.e. ignoring
> that lint altogether for that version, since it also fails for another
> trait in `bounded.rs` (that is why I knew about this).

As I said on the other thread I'm seeing this with what appears to be
1.85.0 in Debian stable.

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

Re: [PATCH] drm/tyr: suppress unread field warnings

[Danilo Krummrich]

On Thu Jan 22, 2026 at 12:22 PM CET, Mark Brown wrote:
> On Thu, Jan 22, 2026 at 01:58:40AM +0100, Miguel Ojeda wrote:
>
>> From what I understand, this is only reproducible with Rust 1.80.0
>> (unsupported upstream), and was fixed in Rust 1.80.1. Did you
>> reproduce it elsewhere? I asked Mark where his toolchain comes to see
>> what could be done there (e.g. in his distribution).
>> 
>> If it is just in Rust 1.80.0, and if a distribution still uses that
>> one, and for some reason they don't want to use/backport the fix in
>> 1.80.1, then we could consider something more global, i.e. ignoring
>> that lint altogether for that version, since it also fails for another
>> trait in `bounded.rs` (that is why I knew about this).
>
> As I said on the other thread I'm seeing this with what appears to be
> 1.85.0 in Debian stable.

That's pretty odd, I can only reproduce the ones you reported in the linux-next
report with 1.80.0.

If I run 1.85.0, I *instead* see the following ones from clippy:

  CLIPPY [M] drivers/gpu/drm/tyr/tyr.o
warning: operator precedence can trip the unwary
  --> drivers/gpu/drm/tyr/gpu.rs:51:13
   |
51 |             shader_present | u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider parenthesizing your expression: `shader_present | (u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32)`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
   = note: `-W clippy::precedence` implied by `-W clippy::all`
   = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`

warning: operator precedence can trip the unwary
  --> drivers/gpu/drm/tyr/gpu.rs:55:13
   |
55 |             tiler_present | u64::from(regs::GPU_TILER_PRESENT_HI.read(dev, iomem)?) << 32;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider parenthesizing your expression: `tiler_present | (u64::from(regs::GPU_TILER_PRESENT_HI.read(dev, iomem)?) << 32)`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence

warning: operator precedence can trip the unwary
  --> drivers/gpu/drm/tyr/gpu.rs:58:26
   |
58 |         let l2_present = l2_present | u64::from(regs::GPU_L2_PRESENT_HI.read(dev, iomem)?) << 32;
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider parenthesizing your expression: `l2_present | (u64::from(regs::GPU_L2_PRESENT_HI.read(dev, iomem)?) << 32)`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence

I wonder if this is Debian specific?

Re: [PATCH] drm/tyr: suppress unread field warnings

[Miguel Ojeda]

On Thu, Jan 22, 2026 at 8:46 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> If I run 1.85.0, I *instead* see the following ones from clippy:
>
>   CLIPPY [M] drivers/gpu/drm/tyr/tyr.o
> warning: operator precedence can trip the unwary
>   --> drivers/gpu/drm/tyr/gpu.rs:51:13
>    |
> 51 |             shader_present | u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32;
>    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider parenthesizing your expression: `shader_present | (u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32)`
>    |
>    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
>    = note: `-W clippy::precedence` implied by `-W clippy::all`
>    = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`

I took a look at this --  Rust 1.85.0 extended the `precedence` lint
to catch these, and then because it was too much, they split part of
it into a new one called `precedence_bits` which is not enabled by
default, which landed in Rust 1.86.0 (and is not in Rust 1.85.1,
sadly).

    https://github.com/rust-lang/rust-clippy/pull/13743
    https://github.com/rust-lang/rust-clippy/issues/14097
    https://github.com/rust-lang/rust-clippy/pull/14115

I see others in the kernel have written similar expressions with
parenthesis, e.g. for Rust in `ioctl.rs`, and I see a ton of those in
C files too.

Personally, I don't mind seeing the parenthesis, but I know others may
feel like it is obvious.

Now, seeing quite a bunch of parenthesis for this in C files, from
kernel devs and crypto stuff and all over drivers and so on and so
forth, means others definitely do not find it obvious or prefer to be
explicit for extra clarity.

So we can just clean this one up and later enable `precedence_bits`
for newer versions. Or if we decided it is too much, then I guess I
could allow `precedence` on Rust 1.85.0 only.

Cc'ing others in case they want to give their opinion.

Cheers,
Miguel

Re: [PATCH] drm/tyr: suppress unread field warnings

[Alice Ryhl]

On Fri, Jan 23, 2026 at 04:01:42PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 22, 2026 at 8:46 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > If I run 1.85.0, I *instead* see the following ones from clippy:
> >
> >   CLIPPY [M] drivers/gpu/drm/tyr/tyr.o
> > warning: operator precedence can trip the unwary
> >   --> drivers/gpu/drm/tyr/gpu.rs:51:13
> >    |
> > 51 |             shader_present | u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32;
> >    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider parenthesizing your expression: `shader_present | (u64::from(regs::GPU_SHADER_PRESENT_HI.read(dev, iomem)?) << 32)`
> >    |
> >    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence
> >    = note: `-W clippy::precedence` implied by `-W clippy::all`
> >    = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]`
> 
> I took a look at this --  Rust 1.85.0 extended the `precedence` lint
> to catch these, and then because it was too much, they split part of
> it into a new one called `precedence_bits` which is not enabled by
> default, which landed in Rust 1.86.0 (and is not in Rust 1.85.1,
> sadly).
> 
>     https://github.com/rust-lang/rust-clippy/pull/13743
>     https://github.com/rust-lang/rust-clippy/issues/14097
>     https://github.com/rust-lang/rust-clippy/pull/14115
> 
> I see others in the kernel have written similar expressions with
> parenthesis, e.g. for Rust in `ioctl.rs`, and I see a ton of those in
> C files too.
> 
> Personally, I don't mind seeing the parenthesis, but I know others may
> feel like it is obvious.
> 
> Now, seeing quite a bunch of parenthesis for this in C files, from
> kernel devs and crypto stuff and all over drivers and so on and so
> forth, means others definitely do not find it obvious or prefer to be
> explicit for extra clarity.
> 
> So we can just clean this one up and later enable `precedence_bits`
> for newer versions. Or if we decided it is too much, then I guess I
> could allow `precedence` on Rust 1.85.0 only.
> 
> Cc'ing others in case they want to give their opinion.

Having a lint that happens on just one random version is inconvenient,
so I think we should take at least one of these two actions:

1. Disable clippy::precedence on 1.85.0 only.
2. Enable the clippy::precedence_bits lint.

But I am ok with enabling clippy::precedence_bits.

Alice

Re: [PATCH] drm/tyr: suppress unread field warnings

[Miguel Ojeda]

On Fri, Jan 23, 2026 at 4:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> Having a lint that happens on just one random version is inconvenient,
> so I think we should take at least one of these two actions:
>
> 1. Disable clippy::precedence on 1.85.0 only.
> 2. Enable the clippy::precedence_bits lint.

Yeah, in case it wasn't clear, those are the two options I mentioned.

> But I am ok with enabling clippy::precedence_bits.

Great, let's see how others feel about the parenthesis...

Cheers,
Miguel

Re: [PATCH] drm/tyr: suppress unread field warnings

[Gary Guo]

On Fri Jan 23, 2026 at 3:24 PM GMT, Miguel Ojeda wrote:
> On Fri, Jan 23, 2026 at 4:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> Having a lint that happens on just one random version is inconvenient,
>> so I think we should take at least one of these two actions:
>>
>> 1. Disable clippy::precedence on 1.85.0 only.
>> 2. Enable the clippy::precedence_bits lint.
>
> Yeah, in case it wasn't clear, those are the two options I mentioned.
>
>> But I am ok with enabling clippy::precedence_bits.
>
> Great, let's see how others feel about the parenthesis...

I'd like not to have the parenthesis. I think the fact that Clippy needs to rollback
the change tells that it's not popular change.

I think we should just disable the lint for Clippy 1.85.

Best,
Gary

Re: [PATCH] drm/tyr: suppress unread field warnings

[Miguel Ojeda]

On Thu, Jan 22, 2026 at 12:22 PM Mark Brown <broonie@kernel.org> wrote:
>
> As I said on the other thread I'm seeing this with what appears to be
> 1.85.0 in Debian stable.

Danilo asked me if I knew what could explain the fact that Alice and
he couldn't reproduce the dead code warnings while we were in the call
the other day.

One theory we had was whether the toolchain was different -- Debian
sometimes does patch toolchains, so that could have explained it, even
if it would be strange that they would change something that affected
a warning like that.

However, I tested Debian Trixie's toolchain in a fresh container as
well as upstream Rust binaries with next-20260122 (reverting the
`BROKEN` commit) and I can reproduce the unused warnings (and the
Clippy other ones). Same for next-20260121.

Which I guess is expected now, given what Deborah posted -- I can also
reproduce it with e.g. the latest stable (1.93.0) too.

I hope that helps.

Cheers,
Miguel

Re: [PATCH] drm/tyr: suppress unread field warnings

[Alice Ryhl]

On Wed, Jan 21, 2026 at 04:37:46PM -0800, Deborah Brouwer wrote:
> Currently these warnings, as errors, are preventing Tyr driver
> from building:
> 
> error: field `device` is never read
>   --> 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
>    --> 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
> 
> Suppress these errors so that the Tyr driver will build.
> 
> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>

I still don't understand why I couldn't reproduce it myself, but
assuming it's not just an 1.80.0 issue, below is my review:

>  drivers/gpu/drm/tyr/driver.rs | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
> index 2a45d0288825..04c865cb4397 100644
> --- a/drivers/gpu/drm/tyr/driver.rs
> +++ b/drivers/gpu/drm/tyr/driver.rs
> @@ -34,6 +34,7 @@
>  
>  #[pin_data(PinnedDrop)]
>  pub(crate) struct TyrDriver {
> +    #[allow(dead_code)]
>      device: ARef<TyrDevice>,

Let's use #[expect(dead_code)] so we remember to remove this when a user
is added.

>  }
>  
> @@ -193,6 +194,8 @@ struct Clocks {
>  
>  #[pin_data]
>  struct Regulators {
> +    #[allow(dead_code)]
>      mali: Regulator<regulator::Enabled>,
> +    #[allow(dead_code)]
>      sram: Regulator<regulator::Enabled>,

I don't think we intend to ever use these fields - they exist only for
their destructor. In that case, please prefix them with an underscore
instead:

#[pin_data]
struct Regulators {
    _mali: Regulator<regulator::Enabled>,
    _sram: Regulator<regulator::Enabled>,
}

Alice

Re: [PATCH] drm/tyr: suppress unread field warnings

[Deborah Brouwer]

On Thu, Jan 22, 2026 at 08:42:02AM +0000, Alice Ryhl wrote:
> On Wed, Jan 21, 2026 at 04:37:46PM -0800, Deborah Brouwer wrote:
> > Currently these warnings, as errors, are preventing Tyr driver
> > from building:
> > 
> > error: field `device` is never read
> >   --> 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
> >    --> 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
> > 
> > Suppress these errors so that the Tyr driver will build.
> > 
> > Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> 
> I still don't understand why I couldn't reproduce it myself, but
> assuming it's not just an 1.80.0 issue, below is my review:

I think the problem is not actually the rust compiler version, but commit
"0242623384c7 rust: driver: let probe() return impl PinInit<Self, Error>"

Tyr probe() used to return a fully initialized Pin<KBox<Self>>, so the
fields existed in an allocated struct which I suppose counted as
“reading” the fields. But now Tyr probe() returns just a PinInit
closure which doesn’t count as reading these fields.

> 
> >  drivers/gpu/drm/tyr/driver.rs | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
> > index 2a45d0288825..04c865cb4397 100644
> > --- a/drivers/gpu/drm/tyr/driver.rs
> > +++ b/drivers/gpu/drm/tyr/driver.rs
> > @@ -34,6 +34,7 @@
> >  
> >  #[pin_data(PinnedDrop)]
> >  pub(crate) struct TyrDriver {
> > +    #[allow(dead_code)]
> >      device: ARef<TyrDevice>,
> 
> Let's use #[expect(dead_code)] so we remember to remove this when a user
> is added.

Using #[expect(dead_code)] also fails with 'unfulfilled lint expectation'.
So I could keep #[allow(dead_code)] or maybe just use an underscore
_driver too with a comment to explain the issue. What do you think?

> 
> >  }
> >  
> > @@ -193,6 +194,8 @@ struct Clocks {
> >  
> >  #[pin_data]
> >  struct Regulators {
> > +    #[allow(dead_code)]
> >      mali: Regulator<regulator::Enabled>,
> > +    #[allow(dead_code)]
> >      sram: Regulator<regulator::Enabled>,
> 
> I don't think we intend to ever use these fields - they exist only for
> their destructor. In that case, please prefix them with an underscore
> instead:
> 
> #[pin_data]
> struct Regulators {
>     _mali: Regulator<regulator::Enabled>,
>     _sram: Regulator<regulator::Enabled>,
> }
> 
> Alice

Re: [PATCH] drm/tyr: suppress unread field warnings

[Alice Ryhl]

On Thu, Jan 22, 2026 at 11:05:59AM -0800, Deborah Brouwer wrote:
> On Thu, Jan 22, 2026 at 08:42:02AM +0000, Alice Ryhl wrote:
> > On Wed, Jan 21, 2026 at 04:37:46PM -0800, Deborah Brouwer wrote:
> > > Currently these warnings, as errors, are preventing Tyr driver
> > > from building:
> > > 
> > > error: field `device` is never read
> > >   --> 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
> > >    --> 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
> > > 
> > > Suppress these errors so that the Tyr driver will build.
> > > 
> > > Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> > 
> > I still don't understand why I couldn't reproduce it myself, but
> > assuming it's not just an 1.80.0 issue, below is my review:
> 
> I think the problem is not actually the rust compiler version, but commit
> "0242623384c7 rust: driver: let probe() return impl PinInit<Self, Error>"
> 
> Tyr probe() used to return a fully initialized Pin<KBox<Self>>, so the
> fields existed in an allocated struct which I suppose counted as
> “reading” the fields. But now Tyr probe() returns just a PinInit
> closure which doesn’t count as reading these fields.

I see.

> > >  drivers/gpu/drm/tyr/driver.rs | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
> > > index 2a45d0288825..04c865cb4397 100644
> > > --- a/drivers/gpu/drm/tyr/driver.rs
> > > +++ b/drivers/gpu/drm/tyr/driver.rs
> > > @@ -34,6 +34,7 @@
> > >  
> > >  #[pin_data(PinnedDrop)]
> > >  pub(crate) struct TyrDriver {
> > > +    #[allow(dead_code)]
> > >      device: ARef<TyrDevice>,
> > 
> > Let's use #[expect(dead_code)] so we remember to remove this when a user
> > is added.
> 
> Using #[expect(dead_code)] also fails with 'unfulfilled lint expectation'.
> So I could keep #[allow(dead_code)] or maybe just use an underscore
> _driver too with a comment to explain the issue. What do you think?

Ok, let's use _driver for now. If you send a v2, I'll apply it right away.

Alice

Re: [PATCH] drm/tyr: suppress unread field warnings

[Gary Guo]

On Thu Jan 22, 2026 at 8:42 AM GMT, Alice Ryhl wrote:
> On Wed, Jan 21, 2026 at 04:37:46PM -0800, Deborah Brouwer wrote:
>> Currently these warnings, as errors, are preventing Tyr driver
>> from building:
>> 
>> error: field `device` is never read
>>   --> 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
>>    --> 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
>> 
>> Suppress these errors so that the Tyr driver will build.
>> 
>> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
>
> I still don't understand why I couldn't reproduce it myself, but
> assuming it's not just an 1.80.0 issue, below is my review:
>
>>  drivers/gpu/drm/tyr/driver.rs | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/tyr/driver.rs b/drivers/gpu/drm/tyr/driver.rs
>> index 2a45d0288825..04c865cb4397 100644
>> --- a/drivers/gpu/drm/tyr/driver.rs
>> +++ b/drivers/gpu/drm/tyr/driver.rs
>> @@ -34,6 +34,7 @@
>>  
>>  #[pin_data(PinnedDrop)]
>>  pub(crate) struct TyrDriver {
>> +    #[allow(dead_code)]
>>      device: ARef<TyrDevice>,
>
> Let's use #[expect(dead_code)] so we remember to remove this when a user
> is added.
>
>>  }
>>  
>> @@ -193,6 +194,8 @@ struct Clocks {
>>  
>>  #[pin_data]
>>  struct Regulators {
>> +    #[allow(dead_code)]
>>      mali: Regulator<regulator::Enabled>,
>> +    #[allow(dead_code)]
>>      sram: Regulator<regulator::Enabled>,
>
> I don't think we intend to ever use these fields - they exist only for
> their destructor. In that case, please prefix them with an underscore
> instead:
>
> #[pin_data]
> struct Regulators {
>     _mali: Regulator<regulator::Enabled>,
>     _sram: Regulator<regulator::Enabled>,
> }

I wonder if it makes sense to request a feature to mute `dead_code` lint on
certain types which we know are there to represent a registration or resource
enablement.

Currently rustc's dead_code lint has a builtin exception for `PhantomData`, but
I think a lot other types should have the same treatment, this can be useful
even for other core types, e.g `PhantomPinned`.

Best,
Gary

Re: [PATCH] drm/tyr: suppress unread field warnings

[Alice Ryhl]

On Thu, Jan 22, 2026 at 07:32:55PM +0000, Gary Guo wrote:
> On Thu Jan 22, 2026 at 8:42 AM GMT, Alice Ryhl wrote:
> > On Wed, Jan 21, 2026 at 04:37:46PM -0800, Deborah Brouwer wrote:
> >>  #[pin_data]
> >>  struct Regulators {
> >> +    #[allow(dead_code)]
> >>      mali: Regulator<regulator::Enabled>,
> >> +    #[allow(dead_code)]
> >>      sram: Regulator<regulator::Enabled>,
> >
> > I don't think we intend to ever use these fields - they exist only for
> > their destructor. In that case, please prefix them with an underscore
> > instead:
> >
> > #[pin_data]
> > struct Regulators {
> >     _mali: Regulator<regulator::Enabled>,
> >     _sram: Regulator<regulator::Enabled>,
> > }
> 
> I wonder if it makes sense to request a feature to mute `dead_code` lint on
> certain types which we know are there to represent a registration or resource
> enablement.
> 
> Currently rustc's dead_code lint has a builtin exception for `PhantomData`, but
> I think a lot other types should have the same treatment, this can be useful
> even for other core types, e.g `PhantomPinned`.

That'd be an interesting rustc feature. I don't think it's possible
today.

Alice

Re: [PATCH] drm/tyr: suppress unread field warnings

[Miguel Ojeda]

On Fri, Jan 23, 2026 at 6:07 AM Gary Guo <gary@garyguo.net> wrote:
>
> I wonder if it makes sense to request a feature to mute `dead_code` lint on
> certain types which we know are there to represent a registration or resource
> enablement.
>
> Currently rustc's dead_code lint has a builtin exception for `PhantomData`, but
> I think a lot other types should have the same treatment, this can be useful
> even for other core types, e.g `PhantomPinned`.

Added to https://github.com/Rust-for-Linux/linux/issues/355.

Cheers,
Miguel