On Fri, Dec 1, 2023, at 20:37, Philipp Stanner wrote:
> On Fri, 2023-12-01 at 16:26 +0100, Arnd Bergmann wrote:
>>
>> static inline bool struct iomem_is_ioport(void __iomem *p)
>> {
>> #ifdef CONFIG_HAS_IOPORT
>> uintptr_t start = (uintptr_t) PCI_IOBASE;
>> uintptr_t addr = (uintptr_t) p;
>>
>> if (addr >= start && addr < start + IO_SPACE_LIMIT)
>> return true;
>> #endif
>> return false;
>> }
>>
>> > +#else /* CONFIG_GENERIC_IOMAP. Version from lib/iomap.c will be
>> > used.
>> > */
>> > +bool iomem_is_ioport(void __iomem *addr);
>> > +#define ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT
>>
>> I'm not sure what this macro is for, since it appears to
>> do the opposite of what its name suggests: rather than
>> provide the generic version of iomem_is_ioport(), it
>> skips that and provides a custom one to go with lib/iomap.c
>
> Hmmm well now it's getting tricky.
>
> This else-branch is the one where CONFIG_GENERIC_IOMAP is actually set.
>
> I think we're running into the "generic not being generic now that IA64
> has died" problem you were hinting at.
>
> If we build for x86 and have CONFIG_GENERIC set, only then do we want
> iomem_is_ioport() from lib/iomap.c. So the macro serves avoiding a
> collision between symbols. Because lib/iomap.c might be compiled even
> if someone else already has defined iomem_is_ioport().
> I also don't like it, but it was the least bad solution I could come up
> with
> Suggestions?
The best I can think of is to move the lib/iomap.c version
of iomem_is_ioport() to include/asm-generic/iomap.h with
an #ifndef iomem_is_ioport / #define iomem_is_ioport
check around it. This file is only included on parisc, alpha,
sh and when CONFIG_GENERIC_IOMAP is set.
The default version in asm-generic/io.h then just needs
one more #ifdef iomem_is_ioport check around it.
Arnd
