[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5596E351.5090100@redhat.com>
Date: Fri, 03 Jul 2015 13:32:33 -0600
From: Al Stone <ahs3@...hat.com>
To: Hanjun Guo <guohanjun@...wei.com>, Al Stone <al.stone@...aro.org>,
linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
CC: rjw@...ysocki.net, lenb@...nel.org, catalin.marinas@....com,
will.deacon@....com, tglx@...utronix.de, jason@...edaemon.net,
linux-kernel@...r.kernel.org, linaro-acpi@...ts.linaro.org,
linaro-kernel@...ts.linaro.org, patches@...aro.org
Subject: Re: [PATCH v3 1/3] ACPI : introduce macros for using the ACPI specification
version
On 07/02/2015 11:16 PM, Hanjun Guo wrote:
> Hi Al,
>
> On 2015/7/3 7:48, Al Stone wrote:
>> Add the __ACPI_FADT_SPEC_VERSION() helper macro to build a proper version
>> number from a major and minor revision number. Add also macros that use
>> the helper to construct the current version from the values in the FADT
>> (i.e., ACPI_FADT_SPEC_VERSION) and both the 5.1 and 6.0 versions.
>>
>> These macros are added in order to simplify retrieving and comparing ACPI
>> specification version numbers, since this is becoming a more frequent need.
>> In particular, there are some architectures that require at least a certain
>> version of the spec, and there are differences in some structure sizes that
>> have changed with recent versions but can only be tracked by spec version
>> number.
>>
>> Fixes: aeb823bbacc2 (ACPICA: ACPI 6.0: Add changes for FADT table.)
>
> If I understand correctly, will it be (and for next two patches as well):
>
> 0cff8dc0099f (ACPICA: ACPI 6.0: Add changes for MADT table.)?
>
> FADT table update was not introduce any regressions for ARM64
> I think.
>
> Thanks
> Hanjun
>
Right. As I noted in the discussion over v2 of these patches, the FADT
change is correctly implementing a change for ACPI 6.0. However, it is this
change which adds eight bytes to the GICC subtable so that the struct length
and the length field in the GICC subtable no longer match, which is what
causes BAD_MADT_ENTRY to fail.
So, while this commit is correct, the patches in this set are needed to work
around the ambiguity this causes in the spec and the ACPICA implementation of
it.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@...hat.com
-----------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists