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
>
