On Mon, 2023-12-04 at 14:50 +0100, Arnd Bergmann wrote:
On Mon, Dec 4, 2023, at 14:39, Philipp Stanner wrote:
On Mon, 2023-12-04 at 13:38 +0100, Philipp Stanner wrote:
- */
+#if defined(ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT) +bool iomem_is_ioport(void __iomem *addr) { - IO_COND(addr, /* nothing */, iounmap(addr)); + unsigned long port = (unsigned long __force)addr;
+ if (port > PIO_OFFSET && port < PIO_RESERVED)
by the way: Reading that again my instinctive feeling would be that it should be port >= PIO_OFFSET.
This is, however, the exactly copied logic from the IO_COND macro in lib/iomap.c. Is it possible that this macro contains a bug here?
Right, I think that would make more sense, but there is no practical difference as long as I/O port 0 is always unused, which is at least true on x86 because of PCIBIOS_MIN_IO. Commit bb356ddb78b2 ("RISC-V: PCI: Avoid handing out address 0 to devices") describes how setting PCIBIOS_MIN_IO to 0 caused other problems.
Ok, makes sense.
But should we then adjust iomem_is_ioport() in asm-generic/io.h, as well, so that it matches IO_COND()'s behavior?
It currently does this:
uintptr_t start = (uintptr_t)PCI_IOBASE; uintptr_t addr = (uintptr_t)addr_raw;
if (addr >= start && addr < start + IO_SPACE_LIMIT) return true;
and if the architecture does not set PCI_IOBASE, then it's set per default to 0, as well.
So we have two inconsistent definitons
I would just leave the logic consistent with IO_COND here, or maybe use IO_COND() directly, like
IO_COND(addr, return true, /* nothing */); return false;
I considered using it to increase consistency. However, I valued improved readability more. Considering that the mid-term goal is to move it to x86 anyways I'd like to leave it that way for now.
P.
Arnd