linux-kernel - Re: [PATCH 2/2] rust: pci: fix typo in Bar struct's comment

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72=t-U8JTH2JZxkQaW7sbYXjWLpkYkuMd_CuzLoJLbEvgQ@mail.gmail.com>
Date: Sun, 4 Jan 2026 13:45:20 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Marko Turk <mt@...koturk.info>
Cc: Dirk Behme <dirk.behme@...il.com>, Danilo Krummrich <dakr@...nel.org>, dirk.behme@...bosch.com, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 2/2] rust: pci: fix typo in Bar struct's comment

On Sat, Jan 3, 2026 at 10:16 PM Marko Turk <mt@...koturk.info> wrote:
>
> The typo was introduced in the original commit where pci::Bar was added:
> Fixes: bf9651f84b4e ("rust: pci: implement I/O mappable `pci::Bar`")
>
> Should I use that for the Fixes: tag?

I would add both, since it was added in both and thus different set of
stable releases may need to fix it differently (i.e. before and after
the move).

In this case, from a quick look, one is for the current release, so it
doesn't need backport, and the other would need a custom one (since
this commit wouldn't apply) if someone wants to do Option 3.

> Should I do that in the same commit?

If the patch targets the same set of stable releases with the given
`Fixes:` and is trivial (in this case, both are true from a quick
look), then it doesn't matter much either way and may simplify
handling. But, when those are not true, i.e. in the general case,
splitting where possible usually is better and simpler.

I hope that helps!

Cheers,
Miguel