On Fri, 2018-06-08 at 12:33 -0700, Geoff Levand wrote: > On 06/05/2018 12:28 AM, Ian Campbell wrote: > > On Tue, 2018-06-05 at 02:14 +0100, Ben Hutchings wrote: > > > >> I don't think it's OK to cause a regression like this. Since this > is > >> problem affects a specific known platform, the driver ought to > >> recognise it and disable itself automatically. > > > > Indeed, while the Fedora bug upthread claims such a patch wouldn't > be > > upstreamable, AFAIK it is not uncommon to have such quirks for > broken > > firmware based upon DMI identifiers or similar. > > Just to mention it, Mark Salter submitted one of the work-around > patches > for the m400 firmware. The reply from the ACPI maintainer wasn't > very > encouraging. See: > > https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression > related to X-Gene UARTs)
He said: > I'm not convinced that making changes to the core ACPI device > enumeration code in order to cover up for firmware bugs is the right > approach. That response seems fair, changing the core ACPI code at that point indeed doesn't seem correct, especially with a one-off special case (most such things are table and callback driven). I think this is probably something for the arch (or perhaps platform) code to deal with. See for example all the various platform quirks in arch/x86/kernel/acpi/boot.c, which fixup various wrongness and/or disable features. Although I would also note that there seems to be ~200 existing DMI matches under drivers/acpi, just not in the core device enumeration code, I don't read Rafael's response as ruling out a fix somewhere in the ACPI code, just not in the enumeration paths as presented there. > CONFIG_ACPI_APEI allows for automated error reporting, so it is something > that is very desirable[...] I don't think anyone is disputing that, but there are tradeoff to be made here. > Is this an acceptable solution? It should be sent upstream. It at least seems to be a more targetted fix than the one above. Has anyone tried to detect this "slave device attached to itself" situation in a more generic way? Perhaps that would also be worth discussing with upstream too. It's an expected consequence of ARM & co's push towards the ACPI model which effectively requires that the (upstream) kernel must deal with buggy firmware in the field, just like on x86. I don't think it is right that the distros should have to carry and support fixes for this sort of thing, it should be done upstream or by vendors fixing firmware (and I don't hold out much hope for the latter if x86 is any indication, especially for a platform now as old as the m400). Ian.
