linux-kernel - Re: [PATCH v6 4/5] rust: Move register and bitfield macros out of Nova

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] [day] [month] [year] [list]

Message-ID: <aP-KJ0bGAWO7AVO_@arm.com>
Date: Mon, 27 Oct 2025 16:05:11 +0100
From: Beata Michalska <beata.michalska@....com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Joel Fernandes <joelagnelf@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	Alistair Popple <apopple@...dia.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	"bjorn3_gh@...tonmail.com" <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	John Hubbard <jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	"joel@...lfernandes.org" <joel@...lfernandes.org>,
	Elle Rhumsaa <elle@...thered-steel.dev>,
	Yury Norov <yury.norov@...il.com>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	Andrea Righi <arighi@...dia.com>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 4/5] rust: Move register and bitfield macros out of
 Nova

On Mon, Oct 27, 2025 at 10:56:41AM +0100, Danilo Krummrich wrote:
> On Mon Oct 27, 2025 at 10:06 AM CET, Beata Michalska wrote:
> > It's more theoretical at this point, but there are drivers that do rely on
> > information from either DT or ACPI tables for the base address and size of the
> > MMIO region: anything that uses devm_platform_ioremap_resource() or
> > devm_platform_ioremap_resource_byname() I guess.
> 
> Don't get confused, those are two different things: The size of the MMIO region
> (or a PCI BAR) and the const SIZE generic in Io<SIZE> are two different things.
> 
> The former is the actual size of an MMIO region, whereas the latter is the
> minimum size requested by a driver for proper operation.
> 
> For instance, let's assume your driver requests ten contiguous 32-bit registers
> starting at offset zero of an MMIO region.
> 
> In this case you can call req.iomap_sized<0x28>(), because you know that your
> driver is not able to properly work without an MMIO region with at least a width
> of 0x28 bytes.
> 
> The actual size of the MMIO region returned by req.iomap_sized<0x28>() may
> indeed be smaller or larger than that, depending on what is defined in the DT,
> ACPI or PCI BAR.
> 
> If smaller than the const SIZE generic, the call to req.iomap_sized<0x28>() will
> fail, otherwise it will be successful. The actual size of the MMIO region is not
> influenced by the const SIZE generic.
I appreciate the explanation.
I think my confusion here comes from the fact that I was assuming there is an
intent to accommodate different MMIO regions sizes for various device revisions,
and not expecting all drivers to explicitly call the iomap_sized in all cases.
My bad then.
Again, thanks for clarifying that.


---
Best Regards
Beata