[Linux-parport] [PATCH] parport_pc: don't allow driver for SPARC32

[Maciej W. Rozycki]

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@angie.orcam.me.uk/>.

  Maciej