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: 15+ 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-04 12:21 ` Niklas Schnelle
2026-08-04 15:52 ` Arnd Bergmann
[not found] ` <94c3ebc645e80feae1044a57b8b5c82d4d4ff408.camel@linux.ibm.com>
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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox