Bug#900581: linux: Enable Buster kernel features for newer ARM64 servers.
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.
Reply to: