[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2501141605550.50458@angie.orcam.me.uk>
Date: Tue, 14 Jan 2025 16:11:45 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Arnd Bergmann <arnd@...db.de>
cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Mateusz Jończyk <mat.jonczyk@...pl>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
Linux-Arch <linux-arch@...r.kernel.org>, linux-kernel@...r.kernel.org,
Baoquan He <bhe@...hat.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
regressions@...ts.linux.dev
Subject: Re: [REGRESSION] mipsel: no RTC CMOS on the Malta platform in QEMU
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.
Maciej
Powered by blists - more mailing lists