linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ahs3@redhat.com (Al Stone)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/3] ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro
Date: Fri, 03 Jul 2015 13:51:36 -0600	[thread overview]
Message-ID: <5596E7C8.7040809@redhat.com> (raw)
In-Reply-To: <20150703140601.GL25907@e104818-lin.cambridge.arm.com>

On 07/03/2015 08:06 AM, Catalin Marinas wrote:
> On Thu, Jul 02, 2015 at 05:48:35PM -0600, Al Stone wrote:
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 39248d3..a3c26a4 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,17 @@
>>  #include <asm/psci.h>
>>  #include <asm/smp_plat.h>
>>  
>> +/* Macros for consistency checks of the GICC subtable of MADT */
>> +#define ACPI_MADT_GICC_51_LENGTH       76
>> +#define ACPI_MADT_GICC_60_LENGTH       80
>> +
>> +#define BAD_MADT_GICC_ENTRY(entry, end) (                                   \
>> +		(!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
>> +		((ACPI_FADT_SPEC_VERSION == ACPI_FADT_SPEC_VERSION_51) &&   \
>> +		 (entry->header.length != ACPI_MADT_GICC_51_LENGTH))    ||  \
>> +		((ACPI_FADT_SPEC_VERSION == ACPI_FADT_SPEC_VERSION_60) &&   \
>> +		 (entry->header.length != ACPI_MADT_GICC_60_LENGTH)))
> 
> This looks ugly but, well, we could live with this.

Nod.  It's right at the hairy edge of becoming a function, I think.

> However, I'd like to avoid having to extend this macro every time we get
> a new spec released, like 6.1 defining another 80 or 84 etc. So, how
> about we only update this when there is an actual change in the length?
> Something like:
> 
> #define ACPI_MADT_GICC_LENGTH	({					\
> 	u8 length;							\
> 	if (ACPI_FADT_SPEC_VERSION < ACPI_FADT_SPEC_VERSION_6_0)	\
> 		length = 76;						\
> 	else								\
> 		length = 80;						\
> 	length;								\
> })
> 
> or just:
> 
> #define ACPI_MADT_GICC_LENGTH	\
> 	(ACPI_FADT_SPEC_VERSION < ACPI_FADT_SPEC_VERSION_6_0 ? 76 : 80)
> 
> (the latter is simpler but may not look nice if we change it again in
> 6.1; though we could re-write this macro when needed, not a problem)
> 

Perhaps the sanity checking for the MADT subtables needs to be revisited
and a more general solution provided -- this is not the only MADT subtable
with this problem and it may occur again.

Even the versions above are not technically compliant with the spec.  If
we implement what the spec currently says, it might look something like
this:

#define ACPI_MADT_GICC_LENGTH ({					\
	u8 length;							\
	switch (ACPI_FADT_SPEC_VERSION) {				\
	case ACPI_FADT_SPEC_VERSION_5_0:				\
		length = 40;						\
		break;							\
	case ACPI_FADT_SPEC_VERSION_5_1:				\
		length = 76;						\
		break;							\
	default:	/* use 6.0 size */				\
		length = 80;						\
	}								\
	length;								\
})

So it's just messy and there will be a need for change.  Let me think about
making this a function instead of a macro; it may make sense to really fix
BAD_MADT_ENTRY in general instead of just dealing with the GICC subtable,
but it could also be overkill.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------

  reply	other threads:[~2015-07-03 19:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02 23:48 [PATCH v3 0/3] Correct for ACPI 5.1->6.0 spec changes in MADT GICC entries Al Stone
2015-07-02 23:48 ` [PATCH v3 1/3] ACPI : introduce macros for using the ACPI specification version Al Stone
2015-07-03  0:21   ` Rafael J. Wysocki
2015-07-03  5:23     ` Hanjun Guo
2015-07-03 19:22       ` Al Stone
2015-07-03 23:50         ` Rafael J. Wysocki
2015-07-06 21:53           ` Al Stone
2015-07-06 22:44             ` Rafael J. Wysocki
2015-07-03  5:16   ` Hanjun Guo
2015-07-03 19:32     ` Al Stone
2015-07-02 23:48 ` [PATCH v3 2/3] ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro Al Stone
2015-07-03 14:06   ` Catalin Marinas
2015-07-03 19:51     ` Al Stone [this message]
2015-07-03 23:54       ` Rafael J. Wysocki
2015-07-06 10:33         ` Catalin Marinas
2015-07-06 21:20         ` Al Stone
2015-07-02 23:48 ` [PATCH v3 3/3] ACPI / ARM64 : use the new BAD_MADT_GICC_ENTRY macro Al Stone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5596E7C8.7040809@redhat.com \
    --to=ahs3@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).