| Message ID | 1440022048-6285-3-git-send-email-al.stone@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Al, On Wed, Aug 19, 2015 at 11:07:25PM +0100, Al Stone wrote: > Now that we have introduced the bad_madt_entry() function, and that > function is being invoked in acpi_table_parse_madt() for us, there > is no longer any need to use the BAD_MADT_ENTRY macro, or in the case > of arm64, the BAD_MADT_GICC_ENTRY, too. > > Signed-off-by: Al Stone <al.stone@linaro.org> > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > Acked-by: Marc Zyngier <marc.zyngier@arm.com> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Jason Cooper <jason@lakedaemon.net> > --- > arch/arm64/include/asm/acpi.h | 8 -------- > arch/arm64/kernel/smp.c | 2 -- > drivers/irqchip/irq-gic.c | 6 ------ > 3 files changed, 16 deletions(-) How are you planning to merge this (and which kernel are you targetting?) You've got Acks for both arm64 and irqchip, so I guess either of those trees could take it. Will
On 08/20/2015 04:13 AM, Will Deacon wrote: > Hi Al, > > On Wed, Aug 19, 2015 at 11:07:25PM +0100, Al Stone wrote: >> Now that we have introduced the bad_madt_entry() function, and that >> function is being invoked in acpi_table_parse_madt() for us, there >> is no longer any need to use the BAD_MADT_ENTRY macro, or in the case >> of arm64, the BAD_MADT_GICC_ENTRY, too. >> >> Signed-off-by: Al Stone <al.stone@linaro.org> >> Acked-by: Catalin Marinas <catalin.marinas@arm.com> >> Acked-by: Marc Zyngier <marc.zyngier@arm.com> >> Cc: Will Deacon <will.deacon@arm.com> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Jason Cooper <jason@lakedaemon.net> >> --- >> arch/arm64/include/asm/acpi.h | 8 -------- >> arch/arm64/kernel/smp.c | 2 -- >> drivers/irqchip/irq-gic.c | 6 ------ >> 3 files changed, 16 deletions(-) > > How are you planning to merge this (and which kernel are you targetting?) > You've got Acks for both arm64 and irqchip, so I guess either of those > trees could take it. Yeah, this is a little messy. If I can get into 4.2, that would be nice, but not required -- arm64 already has a usable patch for now, and that's the only arch affected. So, 4.3 was my primary target (which is why I worked with linux-next for these). Which tree? Yeesh. 1/5 and 5/5 are ACPI only and required for the rest to work properly; 2/5 is arm64, 3/5 is ia64, and 4/5 is x86. ARM folks are the only ones to have provided acks or reviews, however. I guess I was assuming this would have to go in via Rafael's ACPI tree since those are the key parts -- the arch-specific patches would remove safety checks on MADT subtables without replacing them, if they went in before the ACPI patches. Does that make sense? What do you think?
On Thu, Aug 20, 2015 at 05:57:05PM +0100, Al Stone wrote: > On 08/20/2015 04:13 AM, Will Deacon wrote: > > On Wed, Aug 19, 2015 at 11:07:25PM +0100, Al Stone wrote: > >> Now that we have introduced the bad_madt_entry() function, and that > >> function is being invoked in acpi_table_parse_madt() for us, there > >> is no longer any need to use the BAD_MADT_ENTRY macro, or in the case > >> of arm64, the BAD_MADT_GICC_ENTRY, too. > >> > >> Signed-off-by: Al Stone <al.stone@linaro.org> > >> Acked-by: Catalin Marinas <catalin.marinas@arm.com> > >> Acked-by: Marc Zyngier <marc.zyngier@arm.com> > >> Cc: Will Deacon <will.deacon@arm.com> > >> Cc: Thomas Gleixner <tglx@linutronix.de> > >> Cc: Jason Cooper <jason@lakedaemon.net> > >> --- > >> arch/arm64/include/asm/acpi.h | 8 -------- > >> arch/arm64/kernel/smp.c | 2 -- > >> drivers/irqchip/irq-gic.c | 6 ------ > >> 3 files changed, 16 deletions(-) > > > > How are you planning to merge this (and which kernel are you targetting?) > > You've got Acks for both arm64 and irqchip, so I guess either of those > > trees could take it. > > Yeah, this is a little messy. If I can get into 4.2, that would be nice, > but not required -- arm64 already has a usable patch for now, and that's > the only arch affected. So, 4.3 was my primary target (which is why I > worked with linux-next for these). > > Which tree? Yeesh. 1/5 and 5/5 are ACPI only and required for the rest > to work properly; 2/5 is arm64, 3/5 is ia64, and 4/5 is x86. ARM folks are > the only ones to have provided acks or reviews, however. I guess I was > assuming this would have to go in via Rafael's ACPI tree since those are > the key parts -- the arch-specific patches would remove safety checks on > MADT subtables without replacing them, if they went in before the ACPI > patches. > > Does that make sense? What do you think? Yup, taking it all via Rafael is fine by me. I just didn't want to end up in a situation where you thought something was going via the arm64 tree but I hadn't queued it. Will
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 208cec0..ed7e212 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -19,14 +19,6 @@ #include <asm/cputype.h> #include <asm/smp_plat.h> -/* Macros for consistency checks of the GICC subtable of MADT */ -#define ACPI_MADT_GICC_LENGTH \ - (acpi_gbl_FADT.header.revision < 6 ? 76 : 80) - -#define BAD_MADT_GICC_ENTRY(entry, end) \ - (!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) || \ - (entry)->header.length != ACPI_MADT_GICC_LENGTH) - /* Basic configuration for ACPI */ #ifdef CONFIG_ACPI /* ACPI table mapping after acpi_gbl_permanent_mmap is set */ diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index dbdaacd..66cc8c4 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -451,8 +451,6 @@ acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header, struct acpi_madt_generic_interrupt *processor; processor = (struct acpi_madt_generic_interrupt *)header; - if (BAD_MADT_GICC_ENTRY(processor, end)) - return -EINVAL; acpi_table_print_madt_entry(header); diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index aa3e7b8..848c44c 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -1064,9 +1064,6 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header, processor = (struct acpi_madt_generic_interrupt *)header; - if (BAD_MADT_GICC_ENTRY(processor, end)) - return -EINVAL; - /* * There is no support for non-banked GICv1/2 register in ACPI spec. * All CPU interface addresses have to be the same. @@ -1088,9 +1085,6 @@ gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header, dist = (struct acpi_madt_generic_distributor *)header; - if (BAD_MADT_ENTRY(dist, end)) - return -EINVAL; - dist_phy_base = dist->base_address; return 0; }