On Tue, 1 Jun 2021, Heiner Kallweit wrote:

quoted

Now I'd like to ask, is quality reliable fix still wanted in mainline or rather not? Because I'll personally do my best to create/find a good fix anyway, but if it is of zero interest for mainline, I'll probably not invest much time into communicating it. My understanding was that default rule is "if broken go fix it" but due to the age of both code and hardware, maybe it is considered frozen or some such (I'm just not aware really).

Driver 8139too has no maintainer. And you refer to "mainline" like to a number of developers
who are paid by somebody to maintain all drivers in the kernel. That's not the case in general.
You provided valuable input, and if you'd contribute to improving 8139too and submit patches for
fixing the issue you're facing, this would be much appreciated.

 It's an issue in x86 platform code, not the 8139too driver.  Any option 
card wired to PCI in this system somehow could suffer from it.  Depending 
on how you look at it you may or may not qualify it as a bug though, and 
any solution can be considered a workaround (for a BIOS misfeature) rather 
than a bug fix.

 The question is IMHO legitimate, and I can't speak for x86 platform 
maintainers.  If I were one, I'd accept a reasonable workaround and it 
does not appear to me it would be a very complex one to address this case: 
basically a PCI quirk to set "this southbridge has ELCR at the usual 
location" (if indeed it does; you don't want to blindly poke at random 
port I/O locations in generic code), and then a tweak to `pirq_enable_irq' 
or `pcibios_lookup_irq' as Arnd has suggested.

  Maciej