On 9 June 2015 at 23:52, Al Stone al.stone@linaro.org wrote:
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.
So, IIUC, this is a problem when v5.1 tables are compiled with v6.0 ACPICA tools?
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?
I agree, while option 1 is easier, option 2 seems better since there's some platforms ( although not all are SBSA compliant) shipping out there.
Regards, Ashwin.