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: <af8d2f99-52f1-ae88-126e-cf90bd6cb3b2@infradead.org>
Date:   Thu, 6 Apr 2023 14:31:58 -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:     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>
From:   Randy Dunlap <rdunlap@infradead.org>
In-Reply-To: <alpine.DEB.2.21.2304062144520.44308@angie.orcam.me.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 4/6/23 14:01, Maciej W. Rozycki wrote:
> Hi Sam,
> 
>>>  This looks completely wrong to me, any ordinary PCI parallel port card 
>>> ought just to work as long as you have PCI (S390 is special I'm told).  
>>> What needs to be done is AFAICT just making `parport_pc_find_nonpci_ports' 
>>> in arch/sparc/include/asm/parport.h SPARC64-specific, i.e.:
>>>
>>> static int parport_pc_find_nonpci_ports(int autoirq, int autodma)
>>> {
>>> 	return (IS_ENABLED(CONFIG_SPARC64) &&
>>> 		platform_driver_register(&ecpp_driver));
>>> }
>>>
>>> or suchlike and let the optimiser get rid of all the unwanted unsupported 
>>> stuff.
>>
>> arch/sparc/include/asm/parport.h is sparc64 specific - and it will
>> result in the wrong result if it is pulled in for sparc32 builds.
>> This is what we see today.
>>
>> 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.
> 
>  I don't have a SPARC toolchain handy or I could even try and build it 
> (but I'm sure there are many people around who can do it without bending 
> backwards).

https://mirrors.edge.kernel.org/pub/tools/crosstool/


-- 
~Randy