From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932932AbcH3RzR (ORCPT ); Tue, 30 Aug 2016 13:55:17 -0400 Received: from foss.arm.com ([217.140.101.70]:46408 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932555AbcH3RzQ (ORCPT ); Tue, 30 Aug 2016 13:55:16 -0400 Date: Tue, 30 Aug 2016 18:55:18 +0100 From: Will Deacon To: "Leizhen (ThunderTown)" Cc: Catalin Marinas , linux-arm-kernel , linux-kernel , Rob Herring , Frank Rowand , devicetree , Zefan Li , Xinwei Hu , Tianhong Ding , Hanjun Guo Subject: Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs Message-ID: <20160830175517.GM24906@arm.com> References: <1472024693-12912-1-git-send-email-thunder.leizhen@huawei.com> <1472024693-12912-15-git-send-email-thunder.leizhen@huawei.com> <20160826153550.GI30302@arm.com> <57C16F17.5070609@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57C16F17.5070609@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 27, 2016 at 06:44:39PM +0800, Leizhen (ThunderTown) wrote: > > > On 2016/8/26 23:35, Will Deacon wrote: > > On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote: > >> Update documentation. This limit is unneccessary. > >> > >> Signed-off-by: Zhen Lei > >> Acked-by: Rob Herring > >> --- > >> Documentation/devicetree/bindings/numa.txt | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt > >> index 21b3505..c0ea4a7 100644 > >> --- a/Documentation/devicetree/bindings/numa.txt > >> +++ b/Documentation/devicetree/bindings/numa.txt > >> @@ -48,7 +48,6 @@ distance (memory latency) between all numa nodes. > >> > >> Note: > >> 1. Each entry represents distance from first node to second node. > >> - The distances are equal in either direction. > > > > Hmm, so what happens now if firmware provides a description where both > > distances (in either direction) are supplied, but are different? > I have not known any hardware that the distances of two direction are > different yet Then let's not add support for this just yet. When we have systems that actually need it, we'll be in a much better position to assess the suitability of any patches. At the moment, the whole thing is pretty questionable and it adds needless complication to the code. Will