Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3868796ybl; Mon, 13 Jan 2020 04:08:14 -0800 (PST) X-Google-Smtp-Source: APXvYqyus+Omz2ji2iNwbWtewt8OyxON0P8h9W1cnBrIMmq7JtBOH+diOnqfbTdxIQiFUPS/xSbn X-Received: by 2002:aca:1309:: with SMTP id e9mr12483186oii.7.1578917294420; Mon, 13 Jan 2020 04:08:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578917294; cv=none; d=google.com; s=arc-20160816; b=p3OeaeQEGG1ybVJYZLT96/flXd059hso5+0S8ejq5tCrX3Tj+AQxZdAUOtuivYN+a/ 1op5eq7HKIFYIYJHzPuWQwPXmTS1kHue5h3GcgTZ19jqQDZUo/LWEiFMPdp/08DKAhlF PVkvIQ0B/sfidNGgb9hk7yAgi0Vuks2B1eVy8YorDG92Fx1lE5Wt6qjWMjY8dHbeuAct 86UrfZKYARRHdkxaJWFv9ZJtcJTqqBxqm1Fsqmeo9emceP1rKKTd9VGPyAobrP33bN7O lguAOciISVxQD2JyXwyrGV3zupLckiIbOQivzeDfe++VeC0143W7S4aKS5L3egTKjuEV ud0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from; bh=QPE3Je3AJuWj0VzrlNFRM4bW1FrDafSRDLZxI8cV3BY=; b=imFMSjiUQK+1r0//hKAvZShPK3Zq1sOX79+y3LQbnRoYltXvvI6SOgT7+wz1aKcKHY e+1FRLgdQW//6D6d8xIvJJCBt2cY6J8VHtf2vK/tMHPFrxxzk447hmNhx55MY33IfZoM UgBB8YcWuh/SQLfLBycAqyPnkf74OUcFm8ThLW3OfizRZ3AWVED2wZ7dwXT01Gq9Vj5B P3k8tiG/CZucFw+8ZnGdX8iWU7mgsTexLs5ZBX6v5XBJfyKkyqRt726zmscVz3YvImUz 7ilnqbICRN8FlVQvUnNDI8eVoT6yk2JqseAP0N9rKmUl+iq2SHsFhAEPLDgW3BLms4rW B1Ig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g17si6820918otk.252.2020.01.13.04.08.02; Mon, 13 Jan 2020 04:08:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728766AbgAMMGY convert rfc822-to-8bit (ORCPT + 99 others); Mon, 13 Jan 2020 07:06:24 -0500 Received: from szxga02-in.huawei.com ([45.249.212.188]:2987 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728755AbgAMMGY (ORCPT ); Mon, 13 Jan 2020 07:06:24 -0500 Received: from DGGEMM403-HUB.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 5E17B8A45B5013B38E2E; Mon, 13 Jan 2020 20:06:22 +0800 (CST) Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.174]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Mon, 13 Jan 2020 20:06:12 +0800 From: "Zengtao (B)" To: Sudeep Holla CC: Linuxarm , Greg Kroah-Hartman , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v2] cpu-topology: Skip the exist but not possible cpu nodes Thread-Topic: [PATCH v2] cpu-topology: Skip the exist but not possible cpu nodes Thread-Index: AQHVyExqmWOdrHr7k0CDA2xXZLn68Kfn3yMAgAChbkA= Date: Mon, 13 Jan 2020 12:06:11 +0000 Message-ID: <678F3D1BB717D949B966B68EAEB446ED340E41D1@DGGEMM506-MBX.china.huawei.com> References: <1578725620-39677-1-git-send-email-prime.zeng@hisilicon.com> <20200113101922.GE52694@bogus> In-Reply-To: <20200113101922.GE52694@bogus> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.221.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Sudeep Holla [mailto:sudeep.holla@arm.com] > Sent: Monday, January 13, 2020 6:19 PM > To: Zengtao (B) > Cc: Linuxarm; Greg Kroah-Hartman; Rafael J. Wysocki; Sudeep Holla; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2] cpu-topology: Skip the exist but not possible cpu > nodes > > On Sat, Jan 11, 2020 at 02:53:40PM +0800, Zeng Tao wrote: > > When CONFIG_NR_CPUS is smaller than the cpu nodes defined in the > device > > tree, all the cpu nodes parsing will fail. > > And this is not reasonable for a legal device tree configs. > > In this patch, skip such cpu nodes rather than return an error. > > With CONFIG_NR_CPUS = 128 and cpus nodes num in device tree is > 130, > > The following warning messages will be print during boot: > > CPU node for /cpus/cpu@128 exist but the possible cpu range > is :0-127 > > CPU node for /cpus/cpu@129 exist but the possible cpu range > is :0-127 > > CPU node for /cpus/cpu@130 exist but the possible cpu range > is :0-127 > > > > Signed-off-by: Zeng Tao > > --- > > Changelog: > > v1->v2: > > -Remove redundant -ENODEV assignment in get_cpu_for_node > > -Add comment to describe the get_cpu_for_node return values > > -Add skip process for cpu threads > > -Update the commit log with more detail > > --- > > drivers/base/arch_topology.c | 37 > +++++++++++++++++++++++++++++-------- > > 1 file changed, 29 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/base/arch_topology.c > b/drivers/base/arch_topology.c > > index 5fe44b3..01f0e21 100644 > > --- a/drivers/base/arch_topology.c > > +++ b/drivers/base/arch_topology.c > > @@ -248,22 +248,44 @@ core_initcall(free_raw_capacity); > > #endif > > > > #if defined(CONFIG_ARM64) || defined(CONFIG_RISCV) > > +/* > > + * This function returns the logic cpu number of the node. > > + * There are totally three kinds of return values: > > + * (1) logic cpu number which is > 0. > > + * (2) -ENDEV when the node is valid one which can be found in the > device tree > > + * but there is no possible cpu nodes to match, when the > CONFIG_NR_CPUS is > > + * smaller than cpus node numbers in device tree, this will happen. > It's > > + * suggested to just ignore this case. > > s/ENDEV/ENODEV/ Good catch, thanks. > > Also as I mentioned earlier, I prefer not to add any extra logic here > other than the above comment to make it explicit. This triggers > unnecessary > warnings when someone boots with limited CPUs for valid reasons. > So , what 's your suggestion here? Just keep the comments but remove the warning message print? > > > + * (3) -EINVAL when other errors occur. > > + */ > > static int __init get_cpu_for_node(struct device_node *node) > > { > > - struct device_node *cpu_node; > > + struct device_node *cpu_node, *t; > > int cpu; > > + bool found = false; > > > > cpu_node = of_parse_phandle(node, "cpu", 0); > > if (!cpu_node) > > - return -1; > > + return -EINVAL; > > + > > + for_each_of_cpu_node(t) > > + if (t == cpu_node) { > > + found = true; > > + break; > > + } > > + > > + if (!found) { > > + pr_crit("Unable to find CPU node for %pOF\n", cpu_node); > > + return -EINVAL; > > + } > > > > cpu = of_cpu_node_to_id(cpu_node); > > if (cpu >= 0) > > topology_parse_cpu_capacity(cpu_node, cpu); > > else > > - pr_crit("Unable to find CPU node for %pOF\n", cpu_node); > > + pr_warn("CPU node for %pOF exist but the possible cpu range > is :%*pbl\n", > > + cpu_node, cpumask_pr_args(cpu_possible_mask)); > > > > - of_node_put(cpu_node); > > Why is this dropped ? It's unnecessary here since no one get the node ref. Regards Zengtao