From: "Arnd Bergmann" <arnd@arndb.de>
To: "Danilo Krummrich" <dakr@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Tamir Duberstein" <tamird@kernel.org>,
acourbot@nvidia.com, "Onur Özkan" <work@onurozkan.dev>
Cc: driver-core@lists.linux.dev, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM
Date: Wed, 05 Aug 2026 23:39:35 +0200 [thread overview]
Message-ID: <9fbff830-d1b3-428b-b7b2-205eff41b6d5@app.fastmail.com> (raw)
In-Reply-To: <20260805212920.1996937-1-dakr@kernel.org>
On Wed, Aug 5, 2026, at 23:28, Danilo Krummrich wrote:
> s390 does not provide ioremap()/iounmap() when CONFIG_HAS_IOMEM is not
> set (which requires CONFIG_PCI on that architecture). This causes a
> build failure with Rust enabled on e.g. s390 allnoconfig:
>
> In file included from rust/helpers/helpers.c:68:
> rust/helpers/io.c:8:9: error: call to undeclared function 'ioremap';
> ISO C99 and later do not support implicit function declarations
> [-Wimplicit-function-declaration]
> 8 | return ioremap(offset, size);
> | ^
> rust/helpers/io.c:19:2: error: call to undeclared function 'iounmap';
> ISO C99 and later do not support implicit function declarations
> [-Wimplicit-function-declaration]
> 19 | iounmap(addr);
>
> Guard the C helpers behind #ifdef CONFIG_HAS_IOMEM and cfg-gate the Rust
> io::mem module, such that IoMem, ExclusiveIoMem and IoRequest are not
> available without CONFIG_HAS_IOMEM.
>
> Note that the C API is inconsistent about this. For instance,
> devm_ioremap() has no stub and produces a link failure without
> CONFIG_HAS_IOMEM, whereas devm_platform_ioremap_resource() provides an
> inline stub returning -EINVAL.
>
> The approach taken here (compile-time gating) matches the former, which
> is slightly more appropriate since any driver performing MMIO currently
> requires CONFIG_HAS_IOMEM.
>
> Ideally, s390 should provide ioremap()/iounmap() stubs unconditionally
> (as UML already does), removing the need for any config gating as
> discussed in [1]; a follow-up patch for s390 is expected.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Reported-by: Miguel Ojeda <ojeda@kernel.org>
> Closes: https://lore.kernel.org/all/20260803180931.97202-1-ojeda@kernel.org [1]
> Fixes: 3f70ebe63858 ("s390: Enable Rust support")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Looks good to me overall.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
One question:
> }
> +#endif /* CONFIG_HAS_IOMEM */
>
> __rust_helper u8 rust_helper_readb(const void __iomem *addr)
Can you also hide the actual I/O accessors in this case?
While s390 without CONFIG_PCI still provides the asm-generic
version of those, that is technically a mistake, and it would
be nice not to.
I'm guessing that there is enough kernel code that still expects
these to be present for C, but if all rust code has the correct
HAS_IOMEM dependencies, it would be cleaner not to reference
since there is no correct way to call them without ioremap().
Arnd
next prev parent reply other threads:[~2026-08-05 21:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 21:28 [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM Danilo Krummrich
2026-08-05 21:28 ` [PATCH v2 2/2] rust: io: gate ioremap doctests " Danilo Krummrich
2026-08-05 21:40 ` Arnd Bergmann
2026-08-05 21:39 ` Arnd Bergmann [this message]
2026-08-06 15:47 ` [PATCH v2 1/2] rust: io: gate ioremap/iounmap " Danilo Krummrich
2026-08-06 16:09 ` Arnd Bergmann
2026-08-06 15:58 ` Danilo Krummrich
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=9fbff830-d1b3-428b-b7b2-205eff41b6d5@app.fastmail.com \
--to=arnd@arndb.de \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox