On Tue, Jan 14, 2025, at 17:11, Maciej W. Rozycki wrote:
> On Tue, 14 Jan 2025, Arnd Bergmann wrote:
>> >> 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.
>> >
>> > Shouldn't arch/mips/include/asm/io.h do
>> >
>> > #define PCI_IOBASE mips_io_port_base
>> >
>> > unconditionally, _before_ including <asm-generic/io.h>?
>>
>> Yes, I think this would make the most sense, but the ordering
>> with the PCI initialization needs to be done carefully,
>> to ensure that PCI_IOBASE has its final value before the first
>> call to pci_remap_iospace().
>
> Is defining PCI_IOBASE going to do the right thing for non-PCI MIPS
> platforms, or should the definition be #ifdef CONFIG_PCI rather than
> unconditional? FWIW I think all PCI MIPS platforms support port I/O.
PCI_IOBASE should be defined whenever CONFIG_HAS_IOPORT is set.
Ideally that should allow using the generic inb/outb and
ioread/iowrite helpers from include/asm-generic/io.h, but
unfortunately those don't support the address swizzling required
on SGI and Octeon platforms.
These platforms look like they currently set a NULL pointer
as the I/O port base:
arch/mips/alchemy/common/setup.c: set_io_port_base(0);
arch/mips/ath79/setup.c: set_io_port_base(KSEG1);
arch/mips/bcm63xx/setup.c: set_io_port_base(0);
arch/mips/bmips/setup.c: set_io_port_base(0);
arch/mips/lantiq/prom.c: set_io_port_base((unsigned long) KSEG1);
At least some of these, possibly all, also have a PCI or PCMCIA
host controller driver that sets a different value later
when that bus is probed.
I don't see any I/O space getting set up for ath25, dec, ingenic,
loongson32, pic32, eyeq, nintendo64, and realtek-rtl. It looks to
me like any I/O port access on these turns into a misaligned NULL
pointer dereference, but there is a good chance I'm missing how
it gets set up there.
Arnd.
