From: Geert Uytterhoeven > Sent: 11 April 2023 09:50 > > Hi David, > > On Wed, Apr 5, 2023 at 11:37 PM David Laight <David.Laight@xxxxxxxxxx> wrote: > > From: Linuxppc-dev Arnd Bergmann > > > Sent: 05 April 2023 21:32 > > > > > > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote: > > > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle <schnelle@xxxxxxxxxxxxx> wrote: > > > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote: > > > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O > > > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of > > > >>> the I/O accessor functions inb()/outb() and friends on architectures > > > >>> which can not meaningfully support legacy I/O spaces such as s390. > > > >>> >> > > > >>Gentle ping. As far as I can tell this hasn't been picked to any tree > > > >>sp far but also hasn't seen complains so I'm wondering if I should send > > > >>a new version of the combined series of this patch plus the added > > > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up. > > > > > > > > You need this on a system supporting not just ISA but also PCI. > > > > > > > > Typically on non-x86 architectures this is simply mapped into a memory window. > > > > > > I'm pretty confident that the list is correct here, as the HAS_IOPORT > > > symbol is enabled exactly for the architectures that have a way to > > > map the I/O space. PCIe generally works fine without I/O space, the > > > only exception are drivers for devices that were around as early PCI. > > > > Isn't there a difference between cpu that have inb()/outb() (probably > > only x86?) and architectures (well computer designs) that can generate > > PCI 'I/O' cycles by some means. > > It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100) > > that mapped a chuck of physical address space onto PCMCIA I/O cycles. > > > > If the hardware can map a PCI 'IO' bar into normal kernel address > > space then the bar and accesses can be treated exactly like a memory bar. > > This probably leaves x86 as the outlier where you need (IIRC) io_readl() > > and friends that can generate in/out instructions for those accesses. > > > > There are also all the x86 ISA devices which need in/out instructions. > > But (with the likely exception of the UART) they are pretty much > > platform specific. > > > > So, to my mind at least, HAS_IOPORT is just the wrong question. > > Not all PCI controllers support mapping the I/O bar in MMIO space, so > in general you cannot say that CONFIG_PCI=y means CONFIG_HAS_IOPORT=y. But a CONFIG_HAS_PCI_IO=y would imply CONFIG_HAS_IOPORT=y. It is the former that is more interesting for driver support. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
