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.
>>>=20
>>> I think the implications should be minor without making Rust depend on
>>> CONFIG_HAS_IOMEM.
>>>=20
>>> 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.
>>>=20
>>> [1] https://lore.kernel.org/driver-core/20260803200249.3494259-1-dakr@k=
ernel.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.

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]. O=
f
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#L=
1809
[2] https://elixir.bootlin.com/linux/v7.1.5/source/include/linux/device/dev=
res.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=3Dy, 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=3Dy 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=3Dy 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 su=
cceed
and only the accessors would prevent undefined behavior?

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