From: David Daney <ddaney@caviumnetworks.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>,
David Daney <ddaney@caviumnetworks.com>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org,
devel@acpica.org, linux-kernel@vger.kernel.org,
Robert Richter <rrichter@cavium.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64
Date: Tue, 26 Apr 2016 09:48:28 -0700 [thread overview]
Message-ID: <571F9BDC.5090804@caviumnetworks.com> (raw)
In-Reply-To: <20160426133500.GQ27312@arm.com>
On 04/26/2016 06:35 AM, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 20:15, Will Deacon wrote:
>>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>>>> On 2016/4/26 0:47, David Daney wrote:
[...]
>>>>>> Given that this ACPI series already requires some significant cross-arch
>>>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>>>> get that queued as a pre-requisite.
>>>>>
>>>>> The cleanup patches you mention above are really independent of the ACPI
>>>>> things. I have applied them both before and after the ACPI patches, and
>>>>> both seem to work. With a quick perusal of the ACPI patches nothing
>>>>> jumps out at me as being a candidate for inclusion in the header file
>>>>> cleanup series.
>>>>
>>>> I agree. My patch set is ACPI related enablement, cleanups and
>>>> consolidations, it would be good to merge as a single patch set
>>>> as it's self-contained.
>>>
>>> Up to you. I just thought you might want to avoid having two sets of
>>> cross-arch changes and the associated merging headaches that go with
>>> that.
>>
>> Good point, as I suggested above, it can go with ACPI tree if it's ok
>> to you and Rafael. The problem we have now is that dt based core NUMA
>> support for ARM64 is queued in your tree, that would be the headache.
>
> Sorry, but if you wanted me *not* to queue the patches, then you should
> have said so (similarly, if you wanted a stable branch). I'm not rebasing
> our for-next/core branch now.
I am quite happy with the fact that you put the base device-tree based
NUMA patches on for-next/core.
There is only a very small adjustment to those in the ACPI-NUMA patches
([PATCH v5 06/14] arm64, numa: rework numa_add_memblk()), so I think we
are fine as far as that goes.
My plan is to post a v6 later today that adjusts some of the messages
printed out and adds some Reviewed-by and Acked-by that were accumulated.
David.
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>,
David Daney <ddaney@caviumnetworks.com>,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org,
devel@acpica.org, linux-kernel@vger.kernel.org,
Robert Richter <rrichter@cavium.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64
Date: Tue, 26 Apr 2016 16:48:28 +0000 [thread overview]
Message-ID: <571F9BDC.5090804@caviumnetworks.com> (raw)
In-Reply-To: <20160426133500.GQ27312@arm.com>
On 04/26/2016 06:35 AM, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 20:15, Will Deacon wrote:
>>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>>>> On 2016/4/26 0:47, David Daney wrote:
[...]
>>>>>> Given that this ACPI series already requires some significant cross-arch
>>>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>>>> get that queued as a pre-requisite.
>>>>>
>>>>> The cleanup patches you mention above are really independent of the ACPI
>>>>> things. I have applied them both before and after the ACPI patches, and
>>>>> both seem to work. With a quick perusal of the ACPI patches nothing
>>>>> jumps out at me as being a candidate for inclusion in the header file
>>>>> cleanup series.
>>>>
>>>> I agree. My patch set is ACPI related enablement, cleanups and
>>>> consolidations, it would be good to merge as a single patch set
>>>> as it's self-contained.
>>>
>>> Up to you. I just thought you might want to avoid having two sets of
>>> cross-arch changes and the associated merging headaches that go with
>>> that.
>>
>> Good point, as I suggested above, it can go with ACPI tree if it's ok
>> to you and Rafael. The problem we have now is that dt based core NUMA
>> support for ARM64 is queued in your tree, that would be the headache.
>
> Sorry, but if you wanted me *not* to queue the patches, then you should
> have said so (similarly, if you wanted a stable branch). I'm not rebasing
> our for-next/core branch now.
I am quite happy with the fact that you put the base device-tree based
NUMA patches on for-next/core.
There is only a very small adjustment to those in the ACPI-NUMA patches
([PATCH v5 06/14] arm64, numa: rework numa_add_memblk()), so I think we
are fine as far as that goes.
My plan is to post a v6 later today that adjusts some of the messages
printed out and adds some Reviewed-by and Acked-by that were accumulated.
David.
WARNING: multiple messages have this Message-ID (diff)
From: ddaney@caviumnetworks.com (David Daney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 00/14] ACPI NUMA support for ARM64
Date: Tue, 26 Apr 2016 09:48:28 -0700 [thread overview]
Message-ID: <571F9BDC.5090804@caviumnetworks.com> (raw)
In-Reply-To: <20160426133500.GQ27312@arm.com>
On 04/26/2016 06:35 AM, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 20:15, Will Deacon wrote:
>>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>>>> On 2016/4/26 0:47, David Daney wrote:
[...]
>>>>>> Given that this ACPI series already requires some significant cross-arch
>>>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>>>> get that queued as a pre-requisite.
>>>>>
>>>>> The cleanup patches you mention above are really independent of the ACPI
>>>>> things. I have applied them both before and after the ACPI patches, and
>>>>> both seem to work. With a quick perusal of the ACPI patches nothing
>>>>> jumps out at me as being a candidate for inclusion in the header file
>>>>> cleanup series.
>>>>
>>>> I agree. My patch set is ACPI related enablement, cleanups and
>>>> consolidations, it would be good to merge as a single patch set
>>>> as it's self-contained.
>>>
>>> Up to you. I just thought you might want to avoid having two sets of
>>> cross-arch changes and the associated merging headaches that go with
>>> that.
>>
>> Good point, as I suggested above, it can go with ACPI tree if it's ok
>> to you and Rafael. The problem we have now is that dt based core NUMA
>> support for ARM64 is queued in your tree, that would be the headache.
>
> Sorry, but if you wanted me *not* to queue the patches, then you should
> have said so (similarly, if you wanted a stable branch). I'm not rebasing
> our for-next/core branch now.
I am quite happy with the fact that you put the base device-tree based
NUMA patches on for-next/core.
There is only a very small adjustment to those in the ACPI-NUMA patches
([PATCH v5 06/14] arm64, numa: rework numa_add_memblk()), so I think we
are fine as far as that goes.
My plan is to post a v6 later today that adjusts some of the messages
printed out and adds some Reviewed-by and Acked-by that were accumulated.
David.
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>,
David Daney <ddaney@caviumnetworks.com>,
<linux-arm-kernel@lists.infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
<x86@kernel.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>,
Marc Zyngier <Marc.Zyngier@arm.com>, <linux-ia64@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <devel@acpica.org>,
<linux-kernel@vger.kernel.org>,
Robert Richter <rrichter@cavium.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64
Date: Tue, 26 Apr 2016 09:48:28 -0700 [thread overview]
Message-ID: <571F9BDC.5090804@caviumnetworks.com> (raw)
In-Reply-To: <20160426133500.GQ27312@arm.com>
On 04/26/2016 06:35 AM, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 20:15, Will Deacon wrote:
>>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>>>> On 2016/4/26 0:47, David Daney wrote:
[...]
>>>>>> Given that this ACPI series already requires some significant cross-arch
>>>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>>>> get that queued as a pre-requisite.
>>>>>
>>>>> The cleanup patches you mention above are really independent of the ACPI
>>>>> things. I have applied them both before and after the ACPI patches, and
>>>>> both seem to work. With a quick perusal of the ACPI patches nothing
>>>>> jumps out at me as being a candidate for inclusion in the header file
>>>>> cleanup series.
>>>>
>>>> I agree. My patch set is ACPI related enablement, cleanups and
>>>> consolidations, it would be good to merge as a single patch set
>>>> as it's self-contained.
>>>
>>> Up to you. I just thought you might want to avoid having two sets of
>>> cross-arch changes and the associated merging headaches that go with
>>> that.
>>
>> Good point, as I suggested above, it can go with ACPI tree if it's ok
>> to you and Rafael. The problem we have now is that dt based core NUMA
>> support for ARM64 is queued in your tree, that would be the headache.
>
> Sorry, but if you wanted me *not* to queue the patches, then you should
> have said so (similarly, if you wanted a stable branch). I'm not rebasing
> our for-next/core branch now.
I am quite happy with the fact that you put the base device-tree based
NUMA patches on for-next/core.
There is only a very small adjustment to those in the ACPI-NUMA patches
([PATCH v5 06/14] arm64, numa: rework numa_add_memblk()), so I think we
are fine as far as that goes.
My plan is to post a v6 later today that adjusts some of the messages
printed out and adds some Reviewed-by and Acked-by that were accumulated.
David.
next prev parent reply other threads:[~2016-04-26 16:48 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 1:40 [PATCH v5 00/14] ACPI NUMA support for ARM64 David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 01/14] acpi, numa: Use pr_fmt() instead of printk David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 02/14] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug() David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 03/14] acpi, numa: remove duplicate NULL check David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 04/14] acpi, numa: Move acpi_numa_arch_fixup() to ia64 only David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-26 5:15 ` Hanjun Guo
2016-04-26 5:15 ` [Devel] " Hanjun Guo
2016-04-26 5:15 ` Hanjun Guo
2016-04-26 5:15 ` Hanjun Guo
2016-04-20 1:40 ` [PATCH v5 05/14] acpi, numa: move acpi_numa_slit_init() to drivers/acpi/numa.c David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 06/14] arm64, numa: rework numa_add_memblk() David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 07/14] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init() David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 08/14] acpi, numa: move bad_srat() and srat_disabled() to drivers/acpi/numa.c David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 09/14] acpi, numa: remove unneeded acpi_numa=1 David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 10/14] acpi, numa: Move acpi_numa_memory_affinity_init() to drivers/acpi/numa.c David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 11/14] acpi, numa, srat: Improve SRAT error detection and add messages David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 12/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 7:41 ` Dennis Chen
2016-04-20 7:41 ` Dennis Chen
2016-04-20 7:41 ` Dennis Chen
2016-04-20 7:41 ` Dennis Chen
2016-04-20 8:31 ` Ganapatrao Kulkarni
2016-04-20 8:43 ` Ganapatrao Kulkarni
2016-04-20 8:31 ` Ganapatrao Kulkarni
2016-04-20 8:31 ` Ganapatrao Kulkarni
2016-04-20 16:29 ` David Daney
2016-04-20 16:29 ` David Daney
2016-04-20 16:29 ` David Daney
2016-04-20 16:29 ` David Daney
2016-04-21 10:06 ` Dennis Chen
2016-04-21 10:06 ` Dennis Chen
2016-04-21 10:06 ` Dennis Chen
2016-04-21 10:06 ` Dennis Chen
2016-04-27 1:14 ` David Daney
2016-04-27 1:14 ` David Daney
2016-04-27 1:14 ` David Daney
2016-04-27 1:14 ` David Daney
2016-04-27 4:04 ` Hanjun Guo
2016-04-27 4:04 ` [Devel] " Hanjun Guo
2016-04-27 4:04 ` Hanjun Guo
2016-04-27 4:04 ` Hanjun Guo
2016-04-27 4:04 ` Hanjun Guo
2016-04-27 11:37 ` Dennis Chen
2016-04-27 11:37 ` Dennis Chen
2016-04-27 11:37 ` Dennis Chen
2016-04-27 11:37 ` Dennis Chen
2016-04-27 15:40 ` David Daney
2016-04-27 15:40 ` David Daney
2016-04-27 15:40 ` David Daney
2016-04-27 15:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 13/14] acpi, numa: Enable ACPI based NUMA on ARM64 David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` [PATCH v5 14/14] arm64, acpi, numa: Default enable ACPI_NUMA with NUMA David Daney
2016-04-20 1:40 ` David Daney
2016-04-20 1:40 ` David Daney
2016-04-25 11:13 ` [PATCH v5 00/14] ACPI NUMA support for ARM64 Will Deacon
2016-04-25 11:13 ` Will Deacon
2016-04-25 11:13 ` Will Deacon
2016-04-25 16:47 ` David Daney
2016-04-25 16:47 ` David Daney
2016-04-25 16:47 ` David Daney
2016-04-25 16:47 ` David Daney
2016-04-26 5:31 ` Hanjun Guo
2016-04-26 5:31 ` [Devel] " Hanjun Guo
2016-04-26 5:31 ` Hanjun Guo
2016-04-26 5:31 ` Hanjun Guo
2016-04-26 12:15 ` Will Deacon
2016-04-26 12:15 ` Will Deacon
2016-04-26 12:15 ` Will Deacon
2016-04-26 13:03 ` Hanjun Guo
2016-04-26 13:03 ` [Devel] " Hanjun Guo
2016-04-26 13:03 ` Hanjun Guo
2016-04-26 13:03 ` Hanjun Guo
2016-04-26 13:35 ` Will Deacon
2016-04-26 13:35 ` Will Deacon
2016-04-26 13:35 ` Will Deacon
2016-04-26 16:48 ` David Daney [this message]
2016-04-26 16:48 ` David Daney
2016-04-26 16:48 ` David Daney
2016-04-26 16:48 ` David Daney
2016-04-27 1:49 ` Hanjun Guo
2016-04-27 1:49 ` [Devel] " Hanjun Guo
2016-04-27 1:49 ` Hanjun Guo
2016-04-27 1:49 ` Hanjun Guo
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=571F9BDC.5090804@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=Marc.Zyngier@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david.daney@cavium.com \
--cc=devel@acpica.org \
--cc=fenghua.yu@intel.com \
--cc=frowand.list@gmail.com \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=hpa@zytor.com \
--cc=lenb@kernel.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=lv.zheng@intel.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=robh+dt@kernel.org \
--cc=rrichter@cavium.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.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 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.