Linux s390 Architecture development
 help / color / mirror / Atom feed
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

  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