Message-ID: <a05558c3-8d5c-c389-ba4c-be134c75ac1c@infradead.org>
Date:   Fri, 7 Apr 2023 14:10:53 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Sam Ravnborg <sam@...nborg.org>
Cc:     Niklas Schnelle <schnelle@...ux.ibm.com>,
        linux-kernel@...r.kernel.org,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        sparclinux@...r.kernel.org, linux-parport@...ts.infradead.org
Subject: Re: [PATCH] parport_pc: don't allow driver for SPARC32



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

Powered by blists - more mailing lists