Re: [PATCH] parport_pc: don't allow driver for SPARC32

Randy Dunlap
2023-04-07T21:11:10Z

On 4/7/23 14:01, Maciej W. Rozycki wrote:
> 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.
>

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.

> 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).

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.

> 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.

--
~Randy