Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1396244pxj; Fri, 21 May 2021 13:12:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxl4AT5b9vr+biPFmH6726otPdMhOBRUUueJX3csqN0Wq5lf1/cmbMvtpJnD4leFuLkacGT X-Received: by 2002:a05:6402:7d7:: with SMTP id u23mr13040736edy.196.1621627957485; Fri, 21 May 2021 13:12:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621627957; cv=none; d=google.com; s=arc-20160816; b=mxUi3E1e+GqiSPAEeKsb/WJhP0A72i8dCL6OFTTZ7OSoSvRd0Kws0myA8OgDuuafKP 9uU2fLRzKXGDq/o/4sN2Mhye8atiIa/B39+l0KZ/pXth1XoHJbt9w2T162knrUrMMWq4 FhG0NyAJE8cVE3YBmBCP4aYdYSpD/EIiFCshdKveUBk4+meNb6cunuUICvZVuEfES7dA eTu5Xqfr9roxUPoM7+abtpTQDkm/svJJZRwn4EDgT9Wm2deBf2avg9YQtAWpujIA1F5A l6PQa9Z6t7j9jA+v2NW5EXBVul7BcxgDQXJdCpF8dvFcnvphilZHda+KJwUDhY3/q5yS 3FfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=B/wYYnHWo9E2E1l8xoCZhuUpC95MUnqnQUm4SUKotV0=; b=tFH15Nrptv4GSWlYzA4p5ZQfInzifvgWfEwvNrSaDK4KgqINus8kGVDwaGzzn8FprT WFqSHFukjHsrsh/mkKc0b49WIXm9Gra5qh5TDv55NXctwOoxZoz88DHX3S49RVXqCeQg RjoQqol3uFqt7lDWv1dNvzT2SR9xmldMSUxeAWcRXlJoY16l1C4KYXBF4HALmVLzGzl4 nfAmX3ugokjNiRLiRJ8Q5Ll4Vhqw9a4iZeQbtTeYste/DVPAKgHasIIC1YnN+STOzqy4 qcv57FU8ikXH13d+EIUjmJapyZOQMWlO488/eiWHAxoAcoBcsooSaHOQ6acG/hxgIrtJ djqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e14si6566130edc.52.2021.05.21.13.12.14; Fri, 21 May 2021 13:12:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232244AbhEUKAP (ORCPT + 99 others); Fri, 21 May 2021 06:00:15 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:3647 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230381AbhEUJ6r (ORCPT ); Fri, 21 May 2021 05:58:47 -0400 Received: from dggems701-chm.china.huawei.com (unknown [172.30.72.58]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4FmhmT6WrlzmWxX; Fri, 21 May 2021 17:55:05 +0800 (CST) Received: from dggpemm500023.china.huawei.com (7.185.36.83) by dggems701-chm.china.huawei.com (10.3.19.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 21 May 2021 17:57:23 +0800 Received: from DESKTOP-TMVL5KK.china.huawei.com (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 21 May 2021 17:57:22 +0800 From: Yanan Wang To: Rob Herring , Paul Walmsley , Palmer Dabbelt , Albert Ou CC: , , , , Yanan Wang Subject: [PATCH] Documentation: dt-bindings: Fix incorrect statement Date: Fri, 21 May 2021 17:57:20 +0800 Message-ID: <20210521095720.5592-1-wangyanan55@huawei.com> X-Mailer: git-send-email 2.8.4.windows.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It's found when reading the Doc. In a SMP system, the hierarchy of CPUs now can be defined through four not three entities (socket/cluster/core/thread), so correct the statement to avoid possible confusion. Since we are already there, also drop an extra space and tweak the title alignment. No real context change at all. Cc: Rob Herring Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Signed-off-by: Yanan Wang --- Documentation/devicetree/bindings/cpu/cpu-topology.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/cpu/cpu-topology.txt b/Documentation/devicetree/bindings/cpu/cpu-topology.txt index 9bd530a35d14..8b23a98c283c 100644 --- a/Documentation/devicetree/bindings/cpu/cpu-topology.txt +++ b/Documentation/devicetree/bindings/cpu/cpu-topology.txt @@ -6,7 +6,7 @@ CPU topology binding description 1 - Introduction =========================================== -In a SMP system, the hierarchy of CPUs is defined through three entities that +In a SMP system, the hierarchy of CPUs is defined through four entities that are used to describe the layout of physical CPUs in the system: - socket @@ -75,7 +75,7 @@ whose bindings are described in paragraph 3. The nodes describing the CPU topology (socket/cluster/core/thread) can only be defined within the cpu-map node and every core/thread in the -system must be defined within the topology. Any other configuration is +system must be defined within the topology. Any other configuration is invalid and therefore must be ignored. =========================================== @@ -91,9 +91,9 @@ cpu-map child nodes which do not share a common parent node can have the same name (ie same number N as other cpu-map child nodes at different device tree levels) since name uniqueness will be guaranteed by the device tree hierarchy. -=========================================== +============================================ 3 - socket/cluster/core/thread node bindings -=========================================== +============================================ Bindings for socket/cluster/cpu/thread nodes are defined as follows: -- 2.19.1