On Fri, 7 Apr 2023, Randy Dunlap wrote: > > 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. > > > > If there are 32-bit Sparc machines with PCI slots, we must not have any > users with parallel ports or we should have heard about it IMO. I wouldn't be surprised, parallel ports are not that common nowadays, let alone used. Myself I haven't used a parallel printer for ages now, though I still own a couple of odd other parallel devices, such as a ROM emulator or the firmware download port of an old MIPS development board (actually a regular Super I/O parallel port of said device hijacked by an onboard FPGA for this second purpose if enabled with an onboard rocker switch). That's not the usual stuff people tend to use I suppose. > >> 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. I should have noted this before: ARCH_MIGHT_HAVE_PC_PARPORT is for true ISA or Super I/O parallel ports only. We handle true PCI implementations in a generic platform-agnostic way, as long as the platform implements PCI I/O commands in the host bridge. The latter requirement only excludes a bunch of platforms, most notably S390 and recent 64-bit POWER systems. With Niklas's HAS_IOPORT patches the S390 special case will soon be gone. > > 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). > > >From my reading, if a Sparc32 machine has a PCI port, it might be able to > have a parallel port. However, even with Maciej's suggested code change > instead of my patch, the ebus code is not being compiled for Sparc32 -- only > for Sparc64, so more changes are needed beyond Maciej's suggestion. > > But the documentation that I found refers to Ebus on Sparc4 machines. Well, even though I came across a bunch of SPARC machines in the past I'm not familiar enough with the platform to have an idea what SPARC4 refers to. You can enable CONFIG_PCI for a SPARC32 kernel however, which I infer from there are 32-bit SPARC machines in existence with PCI connectivity. That I find enough for a potential PC-style parallel port configuration with such a system, for as many ports as the availability of slots allows. > > 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. > > /me wishes that we had a Sparc maintainer. What happened to DaveM? In any case after a couple of iterations I have made a succesful build of a 32-bit SPARC toolchain now, which I was able to verify a fix with I have outlined earlier in this thread. Posted as archived at: <https://lore.kernel.org/r/alpine.DEB.2.21.2306182347101.14084@xxxxxxxxxxxxxxxxx/>. Maciej
