From: Ian Campbell <ijc@debian.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Geoff Levand <geoff@infradead.org>,
Riku Voipio <riku.voipio@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
James Morse <james.morse@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Mark Salter <msalter@redhat.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC/RFT PATCH 0/2] disable_hest quirk on HP m400 with bad UEFI firmwware
Date: Tue, 03 Jul 2018 16:47:51 +0100 [thread overview]
Message-ID: <1530632871.9841.139.camel@debian.org> (raw)
In-Reply-To: <CAKv+Gu8VYZ1dCggPjakcvqOxfUCeCAABEADmF2Bm-q3=y3J4ng@mail.gmail.com>
On Tue, 2018-07-03 at 17:17 +0200, Ard Biesheuvel wrote:
> On 3 July 2018 at 10:44, Ian Campbell <ijc@debian.org> wrote:
> > On Thu, 2018-06-28 at 12:25 +0200, Ard Biesheuvel wrote:
> > > I understand the desire to keep running these M400s as long as they
> > > have some life left in them, but the reality is that they are end of
> > > life already, and not many were manufactured to begin with.
> >
> > Linux has a long history of supporting such devices so long as there is
> > someone around willing to keep them running (witness for example how
> > long x86/voyager lived with just 1 in existence in a motivated
> > developer's basement, probably some number of entire architectures and
> > I bet a not insubstantial chunk of the platform support in arch/arm).
> >
>
> I wonder how many such quirks fall into the 'user cannot be bothered
> to add a kernel command line option' category.
I don't know the overall picture, but the very first one I happened to
look at in arch/x86/kernel/acpi/boot.c (picked by grepping for quirk
and looking for acpi) just now was half a dozen quirks setting
acpi_skip_timer_override which is also settable on the command line.
There's also a bunch in there which just disable ACPI completely which
is also possible on the command line.
My gut feeling is that these are the rule not the exception.
> > So, I think DMI quirks are probably, in reality, inevitable unless
> > you
> > think firmware authors are going to be infaliable or the
> > testing/certification suites never has any gaps in it.
> >
>
> Oh, obviously. But this is exactly my point about flood gates: we know
> we need implement support for them, but that fact alone does not
> justify adding quirks for dead platforms for issues that can be
> trivially worked around.
Is m400 really dead? There certainly seem to be people around who care
about keeping it running and have access to them.
> On a related note: what we *could* do to accommodate platforms such as
> m400 that are affected by quirks that can be worked around by a
> command line parameter: we could teach the stub to look at the
> contents of the 'LinuxExtraArgs' EFI environment variable and append
> it to the kernel command line. This is trivial to implement, given
> that we already manipulate and parse the command line in the stub, and
> would allow for a 'fix and forget' tweak to be applied to such
> platforms., without having to accumulate quirks for broken platforms
> that are difficult to remove later.
Ideally the quirk would be a single entry in a table, which is
unobtrusive enough not to worry about removing.
Ian.
WARNING: multiple messages have this Message-ID (diff)
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 16:47:51 +0100 [thread overview]
Message-ID: <1530632871.9841.139.camel@debian.org> (raw)
In-Reply-To: <CAKv+Gu8VYZ1dCggPjakcvqOxfUCeCAABEADmF2Bm-q3=y3J4ng@mail.gmail.com>
On Tue, 2018-07-03 at 17:17 +0200, Ard Biesheuvel wrote:
> On 3 July 2018 at 10:44, Ian Campbell <ijc@debian.org> wrote:
> > On Thu, 2018-06-28 at 12:25 +0200, Ard Biesheuvel wrote:
> > > I understand the desire to keep running these M400s as long as they
> > > have some life left in them, but the reality is that they are end of
> > > life already, and not many were manufactured to begin with.
> >
> > Linux has a long history of supporting such devices so long as there is
> > someone around willing to keep them running (witness for example how
> > long x86/voyager lived with just 1 in existence in a motivated
> > developer's basement, probably some number of entire architectures and
> > I bet a not insubstantial chunk of the platform support in arch/arm).
> >
>
> I wonder how many such quirks fall into the 'user cannot be bothered
> to add a kernel command line option' category.
I don't know the overall picture, but the very first one I happened to
look at in arch/x86/kernel/acpi/boot.c (picked by grepping for quirk
and looking for acpi) just now was half a dozen quirks setting
acpi_skip_timer_override which is also settable on the command line.
There's also a bunch in there which just disable ACPI completely which
is also possible on the command line.
My gut feeling is that these are the rule not the exception.
> > So, I think DMI quirks are probably, in reality, inevitable unless
> > you
> > think firmware authors are going to be infaliable or the
> > testing/certification suites never has any gaps in it.
> >
>
> Oh, obviously. But this is exactly my point about flood gates: we know
> we need implement support for them, but that fact alone does not
> justify adding quirks for dead platforms for issues that can be
> trivially worked around.
Is m400 really dead? There certainly seem to be people around who care
about keeping it running and have access to them.
> On a related note: what we *could* do to accommodate platforms such as
> m400 that are affected by quirks that can be worked around by a
> command line parameter: we could teach the stub to look at the
> contents of the 'LinuxExtraArgs' EFI environment variable and append
> it to the kernel command line. This is trivial to implement, given
> that we already manipulate and parse the command line in the stub, and
> would allow for a 'fix and forget' tweak to be applied to such
> platforms., without having to accumulate quirks for broken platforms
> that are difficult to remove later.
Ideally the quirk would be a single entry in a table, which is
unobtrusive enough not to worry about removing.
Ian.
next prev parent reply other threads:[~2018-07-03 15:47 UTC|newest]
Thread overview: 36+ 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 ` 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 ` 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:06 ` 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 10:25 ` Ard Biesheuvel
2018-06-28 12:51 ` Lorenzo Pieralisi
2018-06-28 12:51 ` Lorenzo Pieralisi
2018-06-28 14:24 ` James Morse
2018-06-28 14:24 ` James Morse
2018-06-28 16:15 ` Geoff Levand
2018-06-28 16:15 ` Geoff Levand
2018-06-28 20:56 ` Ard Biesheuvel
2018-06-28 20:56 ` Ard Biesheuvel
2018-07-03 8:46 ` Ian Campbell
2018-07-03 8:46 ` Ian Campbell
2018-07-03 8:44 ` Ian Campbell
2018-07-03 8:44 ` Ian Campbell
2018-07-03 15:17 ` Ard Biesheuvel
2018-07-03 15:17 ` Ard Biesheuvel
2018-07-03 15:47 ` Ian Campbell [this message]
2018-07-03 15:47 ` Ian Campbell
2018-07-03 17:12 ` Lorenzo Pieralisi
2018-07-03 17:12 ` Lorenzo Pieralisi
2018-07-03 17:16 ` Ian Campbell
2018-07-03 17:16 ` Ian Campbell
2018-07-03 17:39 ` Lorenzo Pieralisi
2018-07-03 17:39 ` Lorenzo Pieralisi
2018-07-03 19:47 ` Ian Campbell
2018-07-03 19:47 ` Ian Campbell
2018-07-04 9:14 ` Lorenzo Pieralisi
2018-07-04 9:14 ` Lorenzo Pieralisi
2018-07-04 9:47 ` Ard Biesheuvel
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=1530632871.9841.139.camel@debian.org \
--to=ijc@debian.org \
--cc=ard.biesheuvel@linaro.org \
--cc=geoff@infradead.org \
--cc=hanjun.guo@linaro.org \
--cc=james.morse@arm.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=msalter@redhat.com \
--cc=riku.voipio@linaro.org \
--cc=sudeep.holla@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.