[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ce65d897-7fa0-4796-a45a-997b38dc23b2@app.fastmail.com>
Date: Tue, 14 Jan 2025 17:56:46 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>, "Arnd Bergmann" <arnd@...db.de>
Cc: "Geert Uytterhoeven" <geert@...ux-m68k.org>,
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
在2025年1月14日一月 下午4:11,Maciej W. Rozycki写道:
> 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.
I think the right thing to do is to unselect HAS_IOPORT for those
platforms.
Thanks
>
> Maciej
--
- Jiaxun
Powered by blists - more mailing lists