All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Mark Brown" <broonie@kernel.org>
Cc: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
	"Deborah Brouwer" <deborah.brouwer@collabora.com>,
	<dri-devel@lists.freedesktop.org>,
	<rust-for-linux@vger.kernel.org>, <daniel.almeida@collabora.com>,
	<aliceryhl@google.com>, <boris.brezillon@collabora.com>
Subject: Re: [PATCH] drm/tyr: suppress unread field warnings
Date: Thu, 22 Jan 2026 20:46:16 +0100	[thread overview]
Message-ID: <DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org> (raw)
In-Reply-To: <cccf7d2d-fe7c-4b90-8181-ae4cbfacb63f@sirena.org.uk>

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?

  reply	other threads:[~2026-01-22 19:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22  0:37 [PATCH] drm/tyr: suppress unread field warnings Deborah Brouwer
2026-01-22  0:58 ` Miguel Ojeda
2026-01-22  2:11   ` Deborah Brouwer
2026-01-22 11:22   ` Mark Brown
2026-01-22 19:46     ` Danilo Krummrich [this message]
2026-01-23 15:01       ` Miguel Ojeda
2026-01-23 15:10         ` Alice Ryhl
2026-01-23 15:24           ` Miguel Ojeda
2026-01-23 16:56             ` Gary Guo
2026-01-24 13:14     ` Miguel Ojeda
2026-01-22  8:42 ` Alice Ryhl
2026-01-22 19:05   ` Deborah Brouwer
2026-01-23 12:08     ` Alice Ryhl
2026-01-22 19:32   ` Gary Guo
2026-01-23  9:18     ` Alice Ryhl
2026-01-23 13:36     ` 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=DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org \
    --to=dakr@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=boris.brezillon@collabora.com \
    --cc=broonie@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=deborah.brouwer@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.