Hola,

This is a discussion about whether we want to move lib/iomap.c and remove the remaining pci_io(un)map() definition of s390.

That would be followup work on our pci_iounmap() cleanup [1] that was discussed here [2] (but is not yet merged).

The summary from the last discussions was: * GENERIC_IOMAP is not generic anymore, but x86-specific * All (?) archs should be able to use generic pci_iounmap()

I've been looking into GENERIC_IOMAP a bit and am unsure whether that's true. Notably, powerpc seems to do something with it; see platforms/Kconfig:

config PPC_INDIRECT_PIO bool select GENERIC_IOMAP

I've had a few ideas, but don't really want to pursue them until we had a discussion about it: 1. If GENERIC_IOMAP is really x86-specific, that should mean that we could move lib/iomap.c to x86 completely, since that file is only built when that symbol is defined. 2. If it's moved to x86, the question arises whether it's possible to provide exact variants for lib/iomap.c's PIO_* constants. The comment above them in that file hint at those being just rough estimates ("assuming that all the low addresses are always PIO"). 3. To really just have one pci_iounmap(), we'd have to jump into s390 and replace its pci_iounmap(), which might be a bad idea since it also has its own pci_iomap().

So my tendency would be to leave s390 alone, figure out what's going on with powerpc and then, if possible, move lib/iomap.c to x86 and consequently have the second "generic" definition of iomem_is_ioport() from asm-generic/iomap.h removed.

Ideas?

P.

[1] https://lore.kernel.org/all/20231213104922.13894-1-pstanner@redhat.com/ [2] https://lore.kernel.org/all/619ea619-29e4-42fb-9b27-1d1a32e0ee66@app.fastmai...