[PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

[PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

[Danilo Krummrich]

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>
---
Changes in v2:
  - Gate the entire io::mem module with #[cfg(CONFIG_HAS_IOMEM)] instead of
    providing a runtime stub returning -EINVAL.
  - Expand the commit message, and note about the existing inconsistency of
    handling CONFIG_HAS_IOMEM and a potential follow-up.
---
 rust/helpers/io.c       | 2 ++
 rust/kernel/io.rs       | 1 +
 rust/kernel/platform.rs | 9 +++++----
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/rust/helpers/io.c b/rust/helpers/io.c
index 397810864a24..1edbc274951c 100644
--- a/rust/helpers/io.c
+++ b/rust/helpers/io.c
@@ -3,6 +3,7 @@
 #include <linux/io.h>
 #include <linux/ioport.h>
 
+#ifdef CONFIG_HAS_IOMEM
 __rust_helper void __iomem *rust_helper_ioremap(phys_addr_t offset, size_t size)
 {
 	return ioremap(offset, size);
@@ -18,6 +19,7 @@ __rust_helper void rust_helper_iounmap(void __iomem *addr)
 {
 	iounmap(addr);
 }
+#endif /* CONFIG_HAS_IOMEM */
 
 __rust_helper u8 rust_helper_readb(const void __iomem *addr)
 {
diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
index fcc7678fd9e3..d30bb5c6d4fc 100644
--- a/rust/kernel/io.rs
+++ b/rust/kernel/io.rs
@@ -9,6 +9,7 @@
     prelude::*, //
 };
 
+#[cfg(CONFIG_HAS_IOMEM)]
 pub mod mem;
 pub mod poll;
 pub mod register;
diff --git a/rust/kernel/platform.rs b/rust/kernel/platform.rs
index 9b362e0495d3..d41555a4b31d 100644
--- a/rust/kernel/platform.rs
+++ b/rust/kernel/platform.rs
@@ -17,10 +17,7 @@
         from_result,
         to_result, //
     },
-    io::{
-        mem::IoRequest,
-        Resource, //
-    },
+    io::Resource,
     irq::{
         self,
         IrqRequest, //
@@ -31,6 +28,9 @@
     ThisModule, //
 };
 
+#[cfg(CONFIG_HAS_IOMEM)]
+use crate::io::mem::IoRequest;
+
 use core::{
     marker::PhantomData,
     mem::offset_of,
@@ -307,6 +307,7 @@ pub fn resource_by_name(&self, name: &CStr) -> Option<&Resource> {
     }
 }
 
+#[cfg(CONFIG_HAS_IOMEM)]
 impl Device<Bound> {
     /// Returns an `IoRequest` for the resource at `index`, if any.
     pub fn io_request_by_index(&self, index: u32) -> Option<IoRequest<'_>> {

base-commit: 667d0fb32149f023b8b34a1f6f3d384556eafb5a
-- 
2.55.0

[PATCH v2 2/2] rust: io: gate ioremap doctests on CONFIG_HAS_IOMEM

[Danilo Krummrich]

The doc examples in io.rs and devres.rs directly call
bindings::ioremap() and bindings::iounmap(), which do not exist when
CONFIG_HAS_IOMEM is not set. This causes build failures with
CONFIG_RUST_KERNEL_DOCTESTS=y on such configurations (e.g. s390
allnoconfig).

Gate the affected doctests with `#![cfg(CONFIG_HAS_IOMEM)]` so they are
skipped when IOMEM is unavailable.

Fixes: 3f70ebe63858 ("s390: Enable Rust support")
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
---
 rust/kernel/devres.rs | 1 +
 rust/kernel/io.rs     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/rust/kernel/devres.rs b/rust/kernel/devres.rs
index 11ce500e9b76..8ff8aedf251a 100644
--- a/rust/kernel/devres.rs
+++ b/rust/kernel/devres.rs
@@ -59,6 +59,7 @@ struct Inner<T> {
 /// # Examples
 ///
 /// ```no_run
+/// # #![cfg(CONFIG_HAS_IOMEM)]
 /// use kernel::{
 ///     bindings,
 ///     device::{
diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
index d30bb5c6d4fc..d4063ee41200 100644
--- a/rust/kernel/io.rs
+++ b/rust/kernel/io.rs
@@ -81,6 +81,7 @@ pub fn maxsize(&self) -> usize {
 /// # Examples
 ///
 /// ```no_run
+/// # #![cfg(CONFIG_HAS_IOMEM)]
 /// use kernel::{
 ///     bindings,
 ///     ffi::c_void,
-- 
2.55.0

Re: [PATCH v2 2/2] rust: io: gate ioremap doctests on CONFIG_HAS_IOMEM

[Arnd Bergmann]

On Wed, Aug 5, 2026, at 23:28, Danilo Krummrich wrote:
> The doc examples in io.rs and devres.rs directly call
> bindings::ioremap() and bindings::iounmap(), which do not exist when
> CONFIG_HAS_IOMEM is not set. This causes build failures with
> CONFIG_RUST_KERNEL_DOCTESTS=y on such configurations (e.g. s390
> allnoconfig).
>
> Gate the affected doctests with `#![cfg(CONFIG_HAS_IOMEM)]` so they are
> skipped when IOMEM is unavailable.
>
> Fixes: 3f70ebe63858 ("s390: Enable Rust support")
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

[Arnd Bergmann]

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

Re: [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

[Danilo Krummrich]

On Wed Aug 5, 2026 at 11:39 PM CEST, Arnd Bergmann wrote:
> 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().

As things are right now, I think something like in [1] should work, but we'd
also need to cfg-gate every single doc-test that uses I/O primitives, which is
slightly annoying.

In any case, I'm not sure it would be a huge benefit anyway. Unlike in C, where
I/O accessors operate on raw void pointers, the Rust primitives are typed. So,
users have no way of actually calling them without being able to obtain a
mapping in the first place.

- Danilo

[1]

diff --git a/rust/helpers/io.c b/rust/helpers/io.c
index 1edbc274951c..29120ea9d7d8 100644
--- a/rust/helpers/io.c
+++ b/rust/helpers/io.c
@@ -19,7 +19,6 @@ __rust_helper void rust_helper_iounmap(void __iomem *addr)
 {
        iounmap(addr);
 }
-#endif /* CONFIG_HAS_IOMEM */

 __rust_helper u8 rust_helper_readb(const void __iomem *addr)
 {
@@ -108,6 +107,7 @@ __rust_helper void rust_helper_writeq_relaxed(u64 value, void __iomem *addr)
        writeq_relaxed(value, addr);
 }
 #endif
+#endif /* CONFIG_HAS_IOMEM */

 __rust_helper resource_size_t rust_helper_resource_size(struct resource *res)
 {
diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
index d4063ee41200..d91fc2e4ae9b 100644
--- a/rust/kernel/io.rs
+++ b/rust/kernel/io.rs
@@ -728,6 +728,7 @@ fn io_addr_assert<U>(&self, offset: usize) -> usize {
     }
 }

+#[cfg(CONFIG_HAS_IOMEM)]
 /// Implements [`IoCapable`] on `$mmio` for `$ty` using `$read_fn` and `$write_fn`.
 macro_rules! impl_mmio_io_capable {
     ($mmio:ident, $(#[$attr:meta])* $ty:ty, $read_fn:ident, $write_fn:ident) => {
@@ -746,10 +747,14 @@ unsafe fn io_write(&self, value: $ty, address: usize) {
     };
 }

+#[cfg(CONFIG_HAS_IOMEM)]
 // MMIO regions support 8, 16, and 32-bit accesses.
 impl_mmio_io_capable!(Mmio, u8, readb, writeb);
+#[cfg(CONFIG_HAS_IOMEM)]
 impl_mmio_io_capable!(Mmio, u16, readw, writew);
+#[cfg(CONFIG_HAS_IOMEM)]
 impl_mmio_io_capable!(Mmio, u32, readl, writel);
+#[cfg(CONFIG_HAS_IOMEM)]
 // MMIO regions on 64-bit systems also support 64-bit accesses.
 impl_mmio_io_capable!(
     Mmio,
@@ -843,10 +848,14 @@ pub fn relaxed(&self) -> &RelaxedMmio<SIZE> {
     }
 }

+#[cfg(CONFIG_HAS_IOMEM)]
 // MMIO regions support 8, 16, and 32-bit accesses.
 impl_mmio_io_capable!(RelaxedMmio, u8, readb_relaxed, writeb_relaxed);
+#[cfg(CONFIG_HAS_IOMEM)]
 impl_mmio_io_capable!(RelaxedMmio, u16, readw_relaxed, writew_relaxed);
+#[cfg(CONFIG_HAS_IOMEM)]
 impl_mmio_io_capable!(RelaxedMmio, u32, readl_relaxed, writel_relaxed);
+#[cfg(CONFIG_HAS_IOMEM)]
 // MMIO regions on 64-bit systems also support 64-bit accesses.
 impl_mmio_io_capable!(
     RelaxedMmio,

Re: [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

[Arnd Bergmann]

On Thu, Aug 6, 2026, at 17:47, Danilo Krummrich wrote:
> On Wed Aug 5, 2026 at 11:39 PM CEST, Arnd Bergmann wrote:
>> 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().
>
> As things are right now, I think something like in [1] should work, but we'd
> also need to cfg-gate every single doc-test that uses I/O primitives, which is
> slightly annoying.
>
> In any case, I'm not sure it would be a huge benefit anyway. Unlike in C, where
> I/O accessors operate on raw void pointers, the Rust primitives are typed. So,
> users have no way of actually calling them without being able to obtain a
> mapping in the first place.

Right, makes sense.

     Arnd

Re: [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

[Danilo Krummrich]

On Wed,  5 Aug 2026 23:28:35 +0200, Danilo Krummrich wrote:
> [PATCH v2 1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM

Applied, thanks!

  Branch: driver-core-linus
  Tree:   git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git

[1/2] rust: io: gate ioremap/iounmap on CONFIG_HAS_IOMEM
      commit: 4f5f23846d67
[2/2] rust: io: gate ioremap doctests on CONFIG_HAS_IOMEM
      commit: f88db65aece9

The patches will appear in the next linux-next integration (typically within 24
hours on weekdays).

The patches are queued up for Linus's tree and should land in the next -rc
release.