Re: `io{re,un}map()` build error in s390 under `!CONFIG_HAS_IOMEM`

On Wed, 12 Aug 2026, Arnd Bergmann wrote:

> >  AFAICT HAS_IOMEM is all about just having peripherals located in the 
> > CPU's regular memory addressing space.  All the DEC MIPS platforms fall 
> > into this category, never seen PCI/ISA, some have no peripheral bus.
> 
> To me this is more about the driver model: On most architectures,
> you can use portable drivers that use IORESOURCE_MEM resources
> with ioremap() and the do readl()/writel() on those to access
> little-endian registers.

 Obviously I can't speak for the s390, but that's been my observation as 
well -- it is a matter of coding style then rather than HAS_IOMEM being 
inherently PCI/ISA.

> s390 and um only support this conceptually for PCI devices,
> and the HW implementation is different enough that the abstraction
> breaks down in some cases (like memremap()). m68k Amiga is
> similar to decstation I think, in that it has devices that are
> memory mapped, but they are always visible in the kernel address
> space and are accessed through their own abstraction instead of
> readl()/writel(). m68k q40 does have ISA devices with both
> port and memory accesses that can use portable drivers. I think
> other m68k platforms use a mix of ioremap()/readl()/writel() 
> and their own lower-level accessors based on the driver, but
> none of those drivers are shared with another platform.

 On DECstation we actually have driver code shared between TURBOchannel 
peripheral bus and PCI (and possibly EISA) and it obviously uses the 
standard MMIO accessors consistently regardless of the bus binding.

 Then there is code shared between TURBOchannel and platform stuff, also 
with the system models that lack a peripheral bus too.  There is leftover 
code using non-standard accessors still there, but that's really a matter 
of resources needed to clean this up.

 For instance drivers/net/ethernet/amd/declance.c has now been high on my 
priority list to clean up and properly convert from its current mess to a 
regular TURBOchannel/platform device.  The only issue outstanding are MMIO 
barriers, which have never been properly sorted out in a generic way; cf. 
arch/mips/include/asm/io.h and the iobarrier_*() stuff there.

  Maciej