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;
Date:   Thu, 6 Apr 2023 22:32:07 +0200
From:   Sam Ravnborg <sam@ravnborg.org>
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc:     Randy Dunlap <rdunlap@infradead.org>, 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
Subject: Re: [PATCH] parport_pc: don't allow driver for SPARC32
Message-ID: <20230406203207.GA1534216@ravnborg.org>
References: <20230406160548.25721-1-rdunlap@infradead.org>
 <alpine.DEB.2.21.2304062039260.44308@angie.orcam.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.2304062039260.44308@angie.orcam.me.uk>
Precedence: bulk

Hi Maciej,

On Thu, Apr 06, 2023 at 08:49:50PM +0100, Maciej W. Rozycki wrote:
> On Thu, 6 Apr 2023, Randy Dunlap wrote:
> 
> > arch/sparc/kernel/ebus.o is only built for SPARC64.
> > ns87303_lock is only built for SPARC64.
> > arch/sparc/include/asm/parport.h says that it is for sparc64.
> > Various documentation on the internet says that ebus is for UltraSPARC
> > systems (64-bit).
> > 
> > Therefore don't allow PARPORT_PC to be built for SPARC32.
> 
>  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.

Hence, my ack on the patch from Randy.

	Sam