On 06/10/2015 01:37 AM, G Gregory wrote:
On 10 June 2015 at 08:05, Hanjun Guo hanjun.guo@linaro.org wrote:
On 06/10/2015 11:52 AM, Al Stone wrote:
From c9b3456b2d0aa9fa41d5764b81328aedf0892436 Mon Sep 17 00:00:00 2001 From: Al Stoneahs3@redhat.com Date: Tue, 9 Jun 2015 15:50:27 -0600 Subject: [PATCH 1/2] ARM64 / ACPI : make the sanity checks for MADT GICC more robust
The ACPI 5.1 version of the spec is the first to support arm64 properly. The GICC subtable of the MADT is 76 bytes long in the 5.1 spec. However, in the 6.0 spec, the GICC subtable becomes 80 bytes long. The underlying ACPICA engine only knows about the 6.0 version of this subtable, so that the BAD_MADT_ENTRY() macro now fails with firmware compatible with 5.1, even though it is technically correct. The failure in the macro is that it is checking that the struct length from the MADT matches the struct size in ACPICA so that 5.1-compatible structs end up not being allowed.
So, replace the use of the BAD_MADT_ENTRY() macro with a small function that does essentially the same thing but allows for either a 5.1 or a 6.0 struct size from the firmware.
NB: this correction is in arm64-specific code since it is the only architecture currently using the MADT GICC subtable. Changes to the spec are also in progress that may make this patch short-lived, and may make it fit better in the generic ACPI code. In the meantime, this can cause Linux to not boot on some shipping systems.
Spec changes cannot retroactively change old firmware. So this is a nonsense statement.
Graeme
Argh. And not what I meant to say. What I meant was that perhaps the spec change will make this patch more straightforward, or that at some point in the future we can ignore the old firmware and simplify the code. But, you are correct: spec changes cannot retroactively change old firmware -- if it could, our lives would be *so* much easier :).