Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a05558c3-8d5c-c389-ba4c-be134c75ac1c@infradead.org>
Date:   Fri, 7 Apr 2023 14:10:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH] parport_pc: don't allow driver for SPARC32
Content-Language: en-US
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>,
        Sam Ravnborg <sam@ravnborg.org>
Cc:     Niklas Schnelle <schnelle@linux.ibm.com>,
        linux-kernel@vger.kernel.org,
        Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        sparclinux@vger.kernel.org, linux-parport@lists.infradead.org
References: <20230406160548.25721-1-rdunlap@infradead.org>
 <alpine.DEB.2.21.2304062039260.44308@angie.orcam.me.uk>
 <20230406203207.GA1534216@ravnborg.org>
 <alpine.DEB.2.21.2304062144520.44308@angie.orcam.me.uk>
 <20230407200313.GA1655046@ravnborg.org>
 <alpine.DEB.2.21.2304072142290.62619@angie.orcam.me.uk>
From:   Randy Dunlap <rdunlap@infradead.org>
In-Reply-To: <alpine.DEB.2.21.2304072142290.62619@angie.orcam.me.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


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