From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hanjun Guo Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 Date: Tue, 26 Apr 2016 13:31:07 +0800 Message-ID: <571EFD1B.1070609@linaro.org> References: <1461116439-22991-1-git-send-email-ddaney.cavm@gmail.com> <20160425111338.GJ16065@arm.com> <571E4A2A.8070908@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <571E4A2A.8070908@caviumnetworks.com> Sender: linux-kernel-owner@vger.kernel.org To: David Daney , Will Deacon Cc: David Daney , linux-arm-kernel@lists.infradead.org, Mark Rutland , Catalin Marinas , Tony Luck , Fenghua Yu , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, "Rafael J. Wysocki" , Len Brown , Rob Herring , Frank Rowand , Grant Likely , Robert Moore , Lv Zheng , Marc Zyngier , linux-ia64@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, linux-kernel@vger.kernel.org, Robert Richter , David Daney List-Id: linux-acpi@vger.kernel.org Hi Will, David, On 2016/4/26 0:47, David Daney wrote: > On 04/25/2016 04:13 AM, Will Deacon wrote: >> Hi David, >> >> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote: >>> From: David Daney >>> >>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch >>> set introduce the ACPI based configuration to provide NUMA >>> information. >>> >>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the >>> NUMA domain information from SRAT and SLIT table, so parse those two >>> tables to get mappings from cpu/mem to numa node configuration and >>> system locality. >> >> Whilst I've queued the main NUMA series for arm64, I'd really like to >> see more movement on the generic header file cleanups that you posted >> separately: >> >> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com >> > > FWIW: Those patches should still apply. I am carrying them in my > development trees, and have not changed them in any way. > >> >> 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. Thanks Hanjun