From: "Arnd Bergmann" <arnd@arndb.de>
To: "Heiko Carstens" <hca@linux.ibm.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Niklas Schnelle" <schnelle@linux.ibm.com>,
"Gerd Bayer" <gbayer@linux.ibm.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
driver-core@lists.linux.dev,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
linux-s390@vger.kernel.org,
Linux-Arch <linux-arch@vger.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>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Onur Özkan" <work@onurozkan.dev>,
rust-for-linux@vger.kernel.org
Subject: Re: `io{re,un}map()` build error in s390 under `!CONFIG_HAS_IOMEM`
Date: Tue, 04 Aug 2026 12:36:55 +0200 [thread overview]
Message-ID: <33ecacea-ed2a-409c-ab1c-a136e06b1b7a@app.fastmail.com> (raw)
In-Reply-To: <20260804071330.24760Aaf-hca@linux.ibm.com>
On Tue, Aug 4, 2026, at 09:13, Heiko Carstens wrote:
> On Mon, Aug 03, 2026 at 10:09:08PM +0200, Danilo Krummrich wrote:
>> On Mon Aug 3, 2026 at 9:56 PM CEST, Arnd Bergmann wrote:
>> > In theory you should be able to use rust code without PCI MMIO
>> > support, but I can't see any practical downsides to making rust
>> > 'depends on HAS_MMIO' to avoid having to add those #ifdef.
>>
>> I think the implications should be minor without making Rust depend on
>> CONFIG_HAS_IOMEM.
>>
>> I just sent out a fix [1]; the only annoying part is [2], but we should change
>> those doc-tests anyway. For the one in rust/kernel/io.rs we already did in
>> driver-core-next.
>>
>> [1] https://lore.kernel.org/driver-core/20260803200249.3494259-1-dakr@kernel.org/
This looks like you still provide the rust version of ioremap(),
turning what is supposed to be a link failure into a runtime
error.
> I'm wondering if it would make sense to make HAS_IOMEM always available
> on s390, even though it doesn't make too much sense without PCI.
> But at least it would make s390 again a bit less special.
I see that with CONFIG_PCI=y, s390 already falls back to
generic_ioremap_prot() and just maps any phys_addr_t into the
page table as PAGE_KERNEL, regardless of whether this is an MMIO
address or not.
The simple change below would just extend that behavior to !PCI
and make that consistent with CONFIG_PCI=y on machines without
actual PCI hardware. Of course any code that might rely on this
is now a bug that likely never gets caught at build time.
This still relies on implementing the __raw_* helpers as nop
to have the same behavior as the PCI=y version, as the generic
version would just end up dereferencing the invalid pointers.
Arnd
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 84404e6778d5..806782acf6f6 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -173,7 +173,7 @@ config S390
select GENERIC_ENTRY
select GENERIC_GETTIMEOFDAY
select GENERIC_SMP_IDLE_THREAD
- select GENERIC_IOREMAP if PCI
+ select GENERIC_IOREMAP
select GLOB
select HAVE_ALIGNED_STRUCT_PAGE
select HAVE_ARCH_AUDITSYSCALL
@@ -756,9 +756,6 @@ config PCI_NR_FUNCTIONS
endif # PCI
-config HAS_IOMEM
- def_bool PCI
-
config CHSC_SCH
def_tristate m
prompt "Support for CHSC subchannels"
diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
index faddb9aef3b8..fa5a9dd1c47f 100644
--- a/arch/s390/include/asm/io.h
+++ b/arch/s390/include/asm/io.h
@@ -22,30 +22,16 @@ void *xlate_dev_mem_ptr(phys_addr_t phys);
#define kc_unxlate_dev_mem_ptr unxlate_dev_mem_ptr
void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr);
-#define IO_SPACE_LIMIT 0
-
-/*
- * I/O memory mapping functions.
- */
-#define ioremap_prot ioremap_prot
-#define iounmap iounmap
-
#define _PAGE_IOREMAP pgprot_val(PAGE_KERNEL)
#define ioremap_wc(addr, size) \
ioremap_prot((addr), (size), pgprot_writecombine(PAGE_KERNEL))
-static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
-{
- return NULL;
-}
-
-static inline void ioport_unmap(void __iomem *p)
-{
-}
-
#ifdef CONFIG_PCI
+#define ioremap_prot ioremap_prot
+#define iounmap iounmap
+
/*
* s390 needs a private implementation of pci_iomap since ioremap with its
* offset parameter isn't sufficient. That's because BAR spaces are not
@@ -88,6 +74,49 @@ static inline void __iowrite64_copy(void __iomem *to, const void *from,
}
#define __iowrite64_copy __iowrite64_copy
+#else
+/*
+ * ioremap_prot() without PCI behaves like memremap(),
+ * MMIO accessors do nothing
+ */
+#define ioremap_prot generic_ioremap_prot
+#define iounmap generic_iounmap
+static inline u8 __raw_readb(const volatile void __iomem *addr)
+{
+ return 0xff;
+}
+#define __raw_readb __raw_readb
+static inline u16 __raw_readw(const volatile void __iomem *addr)
+{
+ return 0xffff;
+}
+#define __raw_readw __raw_readw
+static inline u32 __raw_readl(const volatile void __iomem *addr)
+{
+ return 0xffffffffu;
+}
+#define __raw_readl __raw_readl
+static inline u64 __raw_readq(const volatile void __iomem *addr)
+{
+ return 0xffffffffffffffffull;
+}
+#define __raw_readq __raw_readq
+static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
+{
+}
+#define __raw_writeb __raw_writeb
+static inline void __raw_writew(u16 val, volatile void __iomem *addr)
+{
+}
+#define __raw_writew __raw_writew
+static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+{
+}
+#define __raw_writel __raw_writel
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+}
+#define __raw_writeq __raw_writeq
#endif /* CONFIG_PCI */
#include <asm-generic/io.h>
diff --git a/init/Kconfig b/init/Kconfig
index 5230d4879b1c..2a4e3ecbfddd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -237,7 +237,6 @@ config INIT_ENV_ARG_LIMIT
config COMPILE_TEST
bool "Compile also drivers which will not load"
- depends on HAS_IOMEM
help
Some drivers can be compiled on a different platform than they are
intended to be run on. Despite they cannot be loaded there (or even
next prev parent reply other threads:[~2026-08-04 10:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 18:09 `io{re,un}map()` build error in s390 under `!CONFIG_HAS_IOMEM` Miguel Ojeda
2026-08-03 19:56 ` Arnd Bergmann
2026-08-03 20:09 ` Danilo Krummrich
2026-08-04 7:13 ` Heiko Carstens
2026-08-04 10:36 ` Arnd Bergmann [this message]
2026-08-04 11:10 ` Danilo Krummrich
2026-08-04 12:02 ` Arnd Bergmann
2026-08-04 12:26 ` Gary Guo
2026-08-05 15:08 ` Danilo Krummrich
2026-08-12 11:19 ` Maciej W. Rozycki
2026-08-12 11:46 ` Arnd Bergmann
2026-08-12 16:59 ` Maciej W. Rozycki
2026-08-04 12:21 ` Niklas Schnelle
2026-08-04 15:52 ` Arnd Bergmann
2026-08-05 15:36 ` Niklas Schnelle
2026-08-05 15:56 ` Arnd Bergmann
2026-08-06 13:25 ` Niklas Schnelle
2026-08-06 13:44 ` Arnd Bergmann
2026-08-06 15:21 ` Geert Uytterhoeven
2026-08-12 11:23 ` Maciej W. Rozycki
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=33ecacea-ed2a-409c-ab1c-a136e06b1b7a@app.fastmail.com \
--to=arnd@arndb.de \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=agordeev@linux.ibm.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gbayer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.