Further cleanups for pci_iounmap() and lib/iomap.c discussion

Further cleanups for pci_iounmap() and lib/iomap.c discussion

[Philipp Stanner]

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.fastmail.com/