From: Arnd Bergmann > Sent: 13 April 2021 14:40 > > On Tue, Apr 13, 2021 at 3:06 PM David Laight <David.Laight@xxxxxxxxxx> wrote: > > > > From: Arnd Bergmann > > > Sent: 13 April 2021 13:58 > > ... > > > The remaining ones (csky, m68k, sparc32) need to be inspected > > > manually to see if they currently support PCI I/O space but in > > > fact use address zero as the base (with large resources) or they > > > should also turn the operations into a NOP. > > > > I'd expect sparc32 to use an ASI to access PCI IO space. > > I can't quite remember whether IO space was supported at all. > > I see this bit in arch/sparc/kernel/leon_pci.c > > * PCI Memory and Prefetchable Memory is direct-mapped. However I/O Space is > * accessed through a Window which is translated to low 64KB in PCI space, the > * first 4KB is not used so 60KB is available. > ... > pci_add_resource_offset(&resources, &info->io_space, > info->io_space.start - 0x1000); > > which means that there is I/O space, which gets accessed through whichever > method readb() uses. Having the offset equal to the resource means that > the '(void *)0' start is correct. It must have been the VMEbus (and maybe sBus) sparc that used an ASI. I do remember issues with Solaris of some PCI cards not liking being assigned a BAR address of zero. That may be why the low 4k IO space isn't assigned here. (I've never run Linux on sparc, just SVR4 and Solaris.) I guess setting PCI_IOBASE to zero is safer when you can't trust drivers not to use inb() instead of readb(). Or whatever io_read() ends up being. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
