On Tue, Jan 14, 2025, at 00:29, Jiaxun Yang wrote:
> 在2025年1月13日一月 下午10:16，Mateusz Jończyk写道：
>> The mediator seems to be that this bad commit causes
>> arch/mips/include/asm/io.h
>> to #include <asm-generic/io.h> at the end. As a side effect, this causes
>> the PCI_IOBASE macro to be defined:
>>
>> #ifndef PCI_IOBASE
>> #define PCI_IOBASE ((void __iomem *)0)
>> #endif
>>
>> That PCI_IOBASE value above is AFAIK incorrect for MIPS (it should be
>> defined to mips_io_port_base as far as I can tell), but this does not
>> matter much here.
>
> You are right, this is what should be done.
>
> A quick fix would be #undef PCI_IOBASE in arch/mips/include/asm/io.h
> just after including #include <asm-generic/io.h>, with ralink and loongson64
> as exception.
>
> In the long term, we should scrutinize platform usage of mips_io_base
> following ralink's approach.
I think we are close to the point of being able to remove the broken
default PCI_IOBASE: the NULL pointer here is almost always wrong, and
mainly existed to shut up build failures on architectures that have
no port I/O at all. I know that sparc32 and m68k have cases that
actually rely on the broken PCI_IOBASE, so those need a local workaround,
not sure if some mips platform also falls into this category, as
I have not looked here in detail.
Hopefully we can get to a point where any reference to port I/O
(inb/outb, PCI_IOPORT, mips_io_port_base, ...) is guarded by
an #ifdef CONFIG_HAS_IOPORT check, and this is set exactly on
those platforms that set mips_io_port_base to a valid address.
Arnd
