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).
NB conversely we have plenty of useless irrelevant stuff presented in
configration even if it genuinely makes no sense and won't ever be used
for the given platform (e.g. some Intel CPU management stuff shown for
RISC-V or even DEC Alpha systems).
Maciej
