From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C8920D0EE2B for ; Tue, 25 Nov 2025 20:48:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EFF8610E50B; Tue, 25 Nov 2025 20:47:35 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 58D6010E4CB; Mon, 27 Oct 2025 15:05:17 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 18DB4169E; Mon, 27 Oct 2025 08:05:09 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 31C583F673; Mon, 27 Oct 2025 08:05:11 -0700 (PDT) Date: Mon, 27 Oct 2025 16:05:11 +0100 From: Beata Michalska To: Danilo Krummrich Cc: Joel Fernandes , "linux-kernel@vger.kernel.org" , "rust-for-linux@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Alexandre Courbot , Alistair Popple , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "bjorn3_gh@protonmail.com" , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , John Hubbard , Timur Tabi , "joel@joelfernandes.org" , Elle Rhumsaa , Yury Norov , Daniel Almeida , Andrea Righi , "nouveau@lists.freedesktop.org" Subject: Re: [PATCH v6 4/5] rust: Move register and bitfield macros out of Nova Message-ID: References: <20251003154748.1687160-1-joelagnelf@nvidia.com> <20251003154748.1687160-5-joelagnelf@nvidia.com> <47d6ab72-1526-457d-990a-928088ba7022@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailman-Approved-At: Tue, 25 Nov 2025 20:47:23 +0000 X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" 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 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