Re: [PATCH v4 1/2] ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro

[Al Stone]

On 07/07/2015 03:25 AM, Will Deacon wrote:
> On Tue, Jul 07, 2015 at 12:16:47AM +0100, Al Stone wrote:
>> From: Al Stone <al.stone@.linaro.org>
>>
>> The BAD_MADT_ENTRY() macro is designed to work for all of the subtables
>> of the MADT.  In the ACPI 5.1 version of the spec, the struct for the
>> GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in
>> ACPI 6.0, the struct is 80 bytes long.  But, there is only one definition
>> in ACPICA for this struct -- and that is the 6.0 version.  Hence, when
>> BAD_MADT_ENTRY() compares the struct size to the length in the GICC
>> subtable, it fails if 5.1 structs are in use, and there are systems in
>> the wild that have them.
>>
>> This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable
>> only, accounting for the difference in specification versions that are
>> possible.  The BAD_MADT_ENTRY() will continue to work as is for all other
>> MADT subtables.
>>
>> This code is being added to an arm64 header file since that is currently
>> the only architecture using the GICC subtable of the MADT.  As a GIC is
>> specific to ARM, it is also unlikely the subtable will be used elsewhere.
>>
>> Fixes: aeb823bbacc2 (ACPICA: ACPI 6.0: Add changes for FADT table.)
>> Signed-off-by: Al Stone <al.stone@xxxxxxxxxx>
>> ---
>>  arch/arm64/include/asm/acpi.h | 8 ++++++++
>>  1 file changed, 8 insertions(+)
> 
> Not the nicest patch I've ever seen, but if it gets things working again:
> 
>   Acked-by: Will Deacon <will.deacon@xxxxxxx>
> 
> Catalin, I assume you're picking these two up for 4.2?
> 
> Will

Yeah, not my favorite either, but it does work.  This will get
cleaned up by fixing the larger problems, I believe, and then
we should be able to remove this one.  That's the plan, at any
rate.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@xxxxxxxxxx
-----------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/