Re: Odd pci_iounmap() declaration rules..
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2021-09-19 22:45:12
Also in:
llvm
On Sun, Sep 19, 2021 at 3:27 PM Linus Torvalds [off-list ref] wrote:
--- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -1047,7 +1047,7 @@ extern void ioport_unmap(void __iomem *p); -#ifndef CONFIG_GENERIC_IOMAP +#ifndef CONFIG_GENERIC_PCI_IOMAP let me go test, I do have an arm64 build environment for this all, but for that commit I had only done parisc, alpha and x86-64.
Hah. That conditional makes a lot more sense that way, but doing that
sensible thing exposes more oddities.
In particular, both arm and arm64 do
select GENERIC_PCI_IOMAP
so they get the bog-standard pci_iomap() from lib/pci_iomap.c. All
good and sensible.
But is there a pci_iounmap() in lib/pci_iomap.c? No. The default
pci_iounmap() is in lib/iomap.c, which arm and arm64 do *not* use,
because they don't have GENERIC_IOMAP.
So those architectures depended on the header file copy, and with that
sane oneliner, the compile part of the build works fine, but then it
ends with
undefined reference to `pci_iounmap'
because that didn't work out at all.
The fix seems to be to just move that odd code from the header file to
lib/pci_iomap.c, and that should make it all JustWork(tm).
That would at least make some of this make more sense. But this is all
a maze of random odd architecture things, so I'll have to look some
more at it.
Linus