public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ACPI: ARM64: support for ACPI_TABLE_UPGRADE
Date: Tue, 17 May 2016 12:44:02 -0400	[thread overview]
Message-ID: <f0bf43ef-0be5-484c-5066-ab1929105b82@redhat.com> (raw)
In-Reply-To: <20160517124629.GE14955@leverpostej>

Hi Mark,

On 05/17/2016 08:46 AM, Mark Rutland wrote:
> On Tue, May 17, 2016 at 03:06:03PM +0300, Aleksey Makarov wrote:
>> From: Jon Masters <jcm@redhat.com>
>>
>> This patch adds support for ACPI_TABLE_UPGRADE for ARM64
> 
> This feels like a tool to paper over problems rather than solve them.

Generally, it's an arrow in the quiver used to triage problems, and then
solve them by getting firmware updates made.

> If vendors are shipping horrendously broken tables today, clearly no
> software has ever really supported them. So why add workarounds?

That's not (always) the case. These patches help with:

1). During development of a platform, it is much easier to debug
problems with tables if you can test replacement ones without having to
respin the firmware. In the server world, you usually don't have the
firmware source code, so to get it respun could be days-weeks even if
you are working with the authors closely. We have practically used this
feature on a number of platforms already and it will continue.

2). They empower (advanced) users and developers to work around problems
that they find on platforms. Sure, we want firmware to always be fixed
and working well, but it is better if folks have the tools.

> Why is this necessary? Is there a particular case for this, or is this
> just for parity with x86?

The use cases are as above. It's also required for parity with x86
functionality on servers.

> IMO it would be better to put pressure on vendors to fix their FW and
> provide sensible OS-agnostic update mechanisms.

It's easier to put pressure on them after we know what the problems are.
I agree that alternative update mechanisms are also good. We also have
the ability (but it is not implemented on ARM) in GRUB2 to override ACPI
tables, BUT it's kinda atrophied on all arches and requires that you
rebuild GRUB with an additional module. The reality is that by
incorporating this feature we are able to provide the same capability
that already exists on x86 systems for ACPI table triage.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

  reply	other threads:[~2016-05-17 16:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 12:06 [PATCH 0/3] ACPI: ARM64: support for ACPI_TABLE_UPGRADE Aleksey Makarov
2016-05-17 12:06 ` [PATCH 1/3] ACPI: table upgrade: use cacheable map for tables Aleksey Makarov
2016-05-18  3:06   ` Zheng, Lv
2016-05-17 12:06 ` [PATCH 2/3] ACPI: table upgrade: move early_initrd_acpi_init() to header file Aleksey Makarov
2016-05-18  1:08   ` Zheng, Lv
2016-05-17 12:06 ` [PATCH 3/3] ACPI: ARM64: support for ACPI_TABLE_UPGRADE Aleksey Makarov
2016-05-17 12:46   ` Mark Rutland
2016-05-17 16:44     ` Jon Masters [this message]
2016-05-17 16:48       ` Jon Masters
2016-05-23 17:56         ` Lorenzo Pieralisi
2016-05-23 18:29           ` Jon Masters
2016-05-23 16:49       ` Mark Rutland
2016-05-18 15:11     ` Aleksey Makarov

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=f0bf43ef-0be5-484c-5066-ab1929105b82@redhat.com \
    --to=jcm@redhat.com \
    --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