Re: Odd pci_iounmap() declaration rules..

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, Sep 19, 2021 at 3:27 PM Linus Torvalds
<torvalds@linux-foundation.org> 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