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
