All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Stone <ahs3@redhat.com>
To: Will Deacon <will.deacon@arm.com>, Al Stone <al.stone@linaro.org>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"patches@linaro.org" <patches@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH v2 2/5] ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
Date: Thu, 20 Aug 2015 10:57:05 -0600	[thread overview]
Message-ID: <55D606E1.4040804@redhat.com> (raw)
In-Reply-To: <20150820101322.GA19328@arm.com>

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?

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

WARNING: multiple messages have this Message-ID (diff)
From: Al Stone <ahs3@redhat.com>
To: Will Deacon <will.deacon@arm.com>, Al Stone <al.stone@linaro.org>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
	"patches@linaro.org" <patches@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH v2 2/5] ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
Date: Thu, 20 Aug 2015 16:57:05 +0000	[thread overview]
Message-ID: <55D606E1.4040804@redhat.com> (raw)
In-Reply-To: <20150820101322.GA19328@arm.com>

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?

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

WARNING: multiple messages have this Message-ID (diff)
From: ahs3@redhat.com (Al Stone)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/5] ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
Date: Thu, 20 Aug 2015 10:57:05 -0600	[thread overview]
Message-ID: <55D606E1.4040804@redhat.com> (raw)
In-Reply-To: <20150820101322.GA19328@arm.com>

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?

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

  reply	other threads:[~2015-08-20 16:57 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 22:07 [PATCH v2 0/5] ACPI: Provide better MADT subtable sanity checks Al Stone
2015-08-19 22:07 ` Al Stone
2015-08-19 22:07 ` Al Stone
2015-08-19 22:07 ` [PATCH v2 1/5] ACPI: add in a bad_madt_entry() function to eventually replace the macro Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-26 15:38   ` Timur Tabi
2015-08-26 15:38     ` Timur Tabi
2015-08-26 15:38     ` Timur Tabi
2015-08-26 20:30     ` Al Stone
2015-08-26 20:30       ` Al Stone
2015-08-26 20:30       ` Al Stone
2015-09-07 15:32   ` Sudeep Holla
2015-09-07 15:32     ` Sudeep Holla
2015-09-07 15:32     ` Sudeep Holla
2015-09-08 23:00     ` Al Stone
2015-09-08 23:00       ` Al Stone
2015-09-08 23:00       ` Al Stone
2015-09-09 19:57     ` Al Stone
2015-09-09 19:57       ` Al Stone
2015-09-09 19:57       ` Al Stone
2015-09-10 16:20       ` Sudeep Holla
2015-09-10 16:20         ` Sudeep Holla
2015-09-10 16:20         ` Sudeep Holla
2015-09-10 20:43         ` Al Stone
2015-09-10 20:43           ` Al Stone
2015-09-10 20:43           ` Al Stone
2015-09-11  8:49           ` Sudeep Holla
2015-09-11  8:49             ` Sudeep Holla
2015-09-11  8:49             ` Sudeep Holla
2015-08-19 22:07 ` [PATCH v2 2/5] ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-20 10:13   ` Will Deacon
2015-08-20 10:13     ` Will Deacon
2015-08-20 10:13     ` Will Deacon
2015-08-20 16:57     ` Al Stone [this message]
2015-08-20 16:57       ` Al Stone
2015-08-20 16:57       ` Al Stone
2015-08-24 10:04       ` Will Deacon
2015-08-24 10:04         ` Will Deacon
2015-08-24 10:04         ` Will Deacon
2015-08-19 22:07 ` [PATCH v2 3/5] ACPI / IA64: remove usage of BAD_MADT_ENTRY Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07 ` [PATCH v2 4/5] ACPI / X86: " Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07 ` [PATCH v2 5/5] ACPI: remove definition of BAD_MADT_ENTRY macro Al Stone
2015-08-19 22:07   ` Al Stone
2015-08-19 22:07   ` 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=55D606E1.4040804@redhat.com \
    --to=ahs3@redhat.com \
    --cc=al.stone@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.