From: ijc@debian.org (Ian Campbell)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/RFT PATCH 0/2] disable_hest quirk on HP m400 with bad UEFI firmwware
Date: Tue, 03 Jul 2018 20:47:15 +0100 [thread overview]
Message-ID: <1530647235.31922.33.camel@debian.org> (raw)
In-Reply-To: <20180703173943.GA11764@red-moon>
On Tue, 2018-07-03 at 18:39 +0100, Lorenzo Pieralisi wrote:
> On Tue, Jul 03, 2018 at 06:16:12PM +0100, Ian Campbell wrote:
> > On Tue, 2018-07-03 at 18:12 +0100, Lorenzo Pieralisi wrote:
> > > I do not think anybody is preventing that, it is just that we do
> not
> > > see the reason for adding a DMI quirk to the mainline kernel to
> enable
> > > a platform with broken firmware that cripples one of the main
> feature
> > > it is supposed to implement, we can go on forever about this but
> that's
> > > the gist.
> >
> > The quirk turns off a broken feature on the platform where it is
> > broken, not everywhere, there's no "crippling" of the feature.
> >
> > Or are you suggesting that you have in mind a way to fix this which
> > makes HEST work even on m400 and renders the quirk unnecessary?
>
> HEST error reporting is broken on those platforms and it is one
> of the main features we expect from FW in ACPI systems, that
> glossing over the legacy nature of m400 platforms.
>
> What I do not understand, and Ard pointed that out already, is why we
> should add a DMI quirk to the mainline kernel (that he tried/is trying
> very hard to prevent since ACPI for ARM64 was merged) to enable a legacy
> platform with missing/broken (HEST) key FW functionality in a
> distribution.
>
> If we answer that question we can merge this series but I see no
> compelling reason for the time being.
These systems still exist in the real world and enabling HEST in the
(generic) kernel configuration causes a regression on those systems.
The advice from upstream Linux maintainers for many years has been for
distros to remain as close as possible to upstream and to take stable
updates early and often. Telling distros to carry patches because a
platform is no longer produced seems to me to be completely counter to
that.
Is it the policy now that users of a platform should no longer upgrade
their kernels once the manufacturer has decided the platform is EOL, or
shortly after when the kernel decides it is no longer worth supporting?
Ian.
next prev parent reply other threads:[~2018-07-03 19:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 10:06 [RFC/RFT PATCH 0/2] disable_hest quirk on HP m400 with bad UEFI firmwware James Morse
2018-06-28 10:06 ` [RFC/RFT PATCH 1/2] efi: Add helper to retrieve runtime version number James Morse
2018-06-28 10:06 ` [RFC/RFT PATCH 2/2] ACPI / APEI: Add DMI matching quirks for platforms that require hest_disable James Morse
2018-06-28 10:25 ` [RFC/RFT PATCH 0/2] disable_hest quirk on HP m400 with bad UEFI firmwware Ard Biesheuvel
2018-06-28 12:51 ` Lorenzo Pieralisi
2018-06-28 14:24 ` James Morse
2018-06-28 16:15 ` Geoff Levand
2018-06-28 20:56 ` Ard Biesheuvel
2018-07-03 8:46 ` Ian Campbell
2018-07-03 8:44 ` Ian Campbell
2018-07-03 15:17 ` Ard Biesheuvel
2018-07-03 15:47 ` Ian Campbell
2018-07-03 17:12 ` Lorenzo Pieralisi
2018-07-03 17:16 ` Ian Campbell
2018-07-03 17:39 ` Lorenzo Pieralisi
2018-07-03 19:47 ` Ian Campbell [this message]
2018-07-04 9:14 ` Lorenzo Pieralisi
2018-07-04 9:47 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1530647235.31922.33.camel@debian.org \
--to=ijc@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).