linux-kernel - Re: [REGRESSION] mipsel: no RTC CMOS on the Malta platform in QEMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2501141707380.50458@angie.orcam.me.uk>
Date: Tue, 14 Jan 2025 19:10:34 +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:

> >> 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.

 Right, this will be more correctly scoped, so #ifdef CONFIG_HAS_IOPORT 
then.

> 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.

 Address swizzling should be generic: for an endianness boundary crossing 
depending on its wiring there's always either a byte-lane or a bit-lane 
matching policy (of course both may be implemented in the same system via 
different mapping windows, such as with the Broadcom SiByte BCM1250 SoC 
though we only use one in Linux, or with some kind of a bus configuration 
register) and either byte swapping or address swizzling is required 
accordingly for the relevant use cases.  But I guess for just a bunch of 
systems that implement the bit-lane matching policy there's little 
incentive for complicating the generic helpers.

> 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.

$ grep set_io_port_base arch/mips/pci/*

reveals some, i.e. alchemy, and bmips I believe uses the generic handler.  
Other ones may not support port I/O after all, especially where the 
platform in question is meant to be used in PCI device mode.

> 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.

 There's no PCI with the dec platform (i.e. either no I/O bus at all or 
TURBOchannel), so the PCI I/O space is irrelevant, and obviously the MIPS 
architecture has no native I/O space.  I don't know about the other ones, 
but I supppose at least some of them could be SoCs or systems with no PCI 
either.

  Maciej