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

On Tue Aug 4, 2026 at 12:36 PM CEST, Arnd Bergmann wrote:
> 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/[email protected]/
>
> This looks like you still provide the rust version of ioremap(),
> turning what is supposed to be a link failure into a runtime
> error.

Which is the standard for many core APIs, such as [1]. However, I do agree that
in this case the correct fix would be to have all architectures provide the
stubs rather than the Rust code.

However, there's already a precedent for this in the kernel, e.g. in [2]. Of
course, it would be better to clean this up, but depending on whether there's
more architectures having this issue (I didn't check) that's separate from a
fix.

[1] https://elixir.bootlin.com/linux/v7.1.5/source/include/linux/regmap.h#L1809
[2] https://elixir.bootlin.com/linux/v7.1.5/source/include/linux/device/devres.h#L115

>> 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.

As mentioned, I didn't check, but if this is the only architecture causing those
issues that'd be the better fix of course.

However, IIUC, your patch below would make ioremap() and friends silenty succeed
and only the accessors would prevent undefined behavior?

In this case I still think ioremap() should just fail.