On Wed, 4 May 2022, Bjorn Helgaas wrote: > > Well, yes, except I would expect POWER9_CPU (and any higher versions we > > eventually get) to clear HAS_IOPORT. Generic configurations (GENERIC_CPU) > > would set HAS_IOPORT of course, as would any lower architecture variants > > that do or may support port I/O (it's not clear to me if there are any > > that do not). Ideally a generic configuration would not issue accesses to > > random MMIO locations for port I/O accesses via `inb'/`outb', etc. for > > systems that do not support port I/O (which it now does, or at least used > > to until recently). > > It would seem weird to me that a module would build and run on a > generic kernel running on POWER9 (with some safe way of handling > inb/outb that don't actually work), but not on a kernel built > specifically for POWER9_CPU. Why? If you say configure your Alpha kernel for ALPHA_JENSEN, a pure EISA system, then you won't get PCI support nor any PCI drivers offered even though a generic Alpha kernel will get them all and still run on a Jensen system. I find that no different from our case here. And if we do ever get TURBOchannel Alpha support, then a generic kernel configuration will offer EISA, PCI and TURBOchannel drivers, while you won't be offered TURBOchannel drivers for a PCI system and vice versa. It would make no sense to me. Please mind that the main objective for system-specific configurations is optimisation, including both size and speed, and a part of the solution is discarding stuff that's irrelevant for the respective system. So in our case we do want any port I/O code not to be there at all in compiled code and consequently any driver that absolutely requires port I/O code to work will have to become a useless stub in its compiled form. What would be the point then of having it there in the first place except to spread confusion? Maciej
