Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752624AbcD0Btt (ORCPT ); Tue, 26 Apr 2016 21:49:49 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:34075 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752327AbcD0Btq (ORCPT ); Tue, 26 Apr 2016 21:49:46 -0400 Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64 To: Will Deacon References: <1461116439-22991-1-git-send-email-ddaney.cavm@gmail.com> <20160425111338.GJ16065@arm.com> <571E4A2A.8070908@caviumnetworks.com> <571EFD1B.1070609@linaro.org> <20160426121547.GL27312@arm.com> <571F671D.70401@linaro.org> <20160426133500.GQ27312@arm.com> Cc: David Daney , 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 From: Hanjun Guo Message-ID: <57201AB0.9050202@linaro.org> Date: Wed, 27 Apr 2016 09:49:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160426133500.GQ27312@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3306 Lines: 79 Hi Will, On 2016/4/26 21:35, 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: >>>>> On 04/25/2016 04:13 AM, Will Deacon wrote: >>>>>> 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. >>> >>> What's your plan for getting them merged? >> >> This patch set touches lots of ACPI related file in arch/x86, >> arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be >> merged via ACPI tree by Rafael with your ack to ARM64 code, does >> it make sense? > > It doesn't touch anything in drivers/acpi/... are you following the link > above? Sorry, my bad, I though you were talking about this ACPI NUMA support for ARM64 patch set. > >>>>>> 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 misread the message above, I'm really sorry if I did something offending you, I didn't mean that. How about this patch set? We only get few comments on it, your comments on it are appreciated. Thanks Hanjun