On Fri, 7 Apr 2023, Sam Ravnborg wrote: > > > Randy's suggestion is fine, as we avoid building parport support > > > for sparc32. If someone shows up and need parport support > > > for sparc32 then we could look into how to enable it. > > > Until then, we are better helped avoiding building the driver. > > > > I disagree. Why artificially prevent perfectly good hardware from > > working with a perfectly good driver especially as the fix is just a > > trivial exercise? And I offered a solution. > > There is no sparc32 with a PC style parallel port, so the parport_pc > have no value for a sparc32 machine. There are PC-style PCI (and PCIe) parallel ports in the form of option cards being sold; I have one in my RISC-V machine (and I had to go through the hassle of figuring out why the heck I am not able to select the driver in configuration; a situation analogous to what Randy's change wants to arrange). You can plug one into any machine that has PCI slots and my understanding from Linux Kconfig files is there are such 32-bit SPARC machines in existence or the dependency on PCI wouldn't offer the driver. Otherwise just don't enable CONFIG_PCI for 32-bit SPARC. Apologies if I wasn't clear enough with my reasoning, although I think the lone presence of the PCI dependency in Kconfig ought have to make it clear. > The sparc32 machines have the parport_sunbpp driver for their parallel > port. That's an onboard device or an SBus option card though, right? > An alternative fix, and better I think, would be to audit all archs > and let the relevant ones select ARCH_MIGHT_HAVE_PC_PARPORT, so we > avoided the ugly "|| (PCI && !S390 && !SPARC32)" case for PARPORT_PC. It's only S390 that is special in that it has a limited set of specially crafted PCI options it can ever support (or so I am told; something about the firmware or suchlike). Any other platform that has PCI slots will handle PC-style PCI parallel port option cards just fine, as long as it supports PCI I/O read/write commands (some systems such as POWER9 machines don't; Niklas Schnelle has been recently working on a generic way to exclude drivers for devices that require PCI port I/O from being offered with systems that have no support for PCI port I/O). Let me know if you find anything here unclear or have any other questions or comments. Maciej
