On Thu, May 05, 2022 at 09:45:14AM +0100, Maciej W. Rozycki wrote: > 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? Good points.
