So, in ACPI 5.1, the GICC subtable of the MADT is 76 bytes long. In the 6.0 version of the spec, the GICC subtable is 80 bytes long. This causes a problem in the code in linux-next, specifically on the APM Mustang. The same problem could exist for any other ACPI tables on arm64 that are 5.1 tables that we are trying to read.
What happens is that the BAD_MADT_ENTRY() macro will fail in these cases, even though the GICC subtable entry is perfectly valid according to the spec. The macro fail because it compares the subtable length contained in the subtable to the length of the struct in ACPICA. Unfortunately, that causes any 5.1 GICC items to be seen as invalid.
Whilst we try to straighten this out in the spec (this seems like something pretty dumb that should not have happened), I've put together two alternative solutions:
-- per Graeme's suggestion, we change it so that we only use ACPI >= 6.0 on arm64; my only objection to this is that it breaks APM Mustangs that are already in use -- on the positive side, it's the simpler of the two patches.
-- or, replace the use of BAD_MADT_ENTRY with a specific function that works around the spec problem, at least until we straighten out what the spec _should_ do; the downside here is that this may be a short term fix, but on the positive side it keeps the change to the only arch that's affected.
I've attached both patches. Opinions on which one to send upstream?