Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7710747ybl; Thu, 16 Jan 2020 04:25:52 -0800 (PST) X-Google-Smtp-Source: APXvYqxgciXvNBji1t4Abpo0UjVrQHUW44fZ3rPR7XpbKDvMaH9WhPtKK0MW/pmnCRL65Q79jMwl X-Received: by 2002:aca:52cd:: with SMTP id g196mr3853961oib.18.1579177552164; Thu, 16 Jan 2020 04:25:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579177552; cv=none; d=google.com; s=arc-20160816; b=aOeuYddY7eDNG6IMowzF5hL4XVAm1TrvKIGfWY1RgY+Eh0ryJ59tZfbtw8sL7doYO+ YwJqQ3VJ42tbFGy4e3ov6SQQw5R04civK2q/QdEzjeJ1n13t2fS3EEzV+SYOOOiKylUN RwfCF8HVnAN7b9hUB1UusqMKyPHxY7wmik6Xpl0kuM7jguWHgOHsAeKCkgyxT/rzC9Bh w1+oO0CIHqxcTGtZFQmf63S1YK84upM1eis6sui+/9Gzhmi9e0k+uPGN1jx7QoLjUgml KefIu86+iNNy4qfOcuDbwkYM0OpRmGUpM/i6guILjOnqN0sGbybwoJzVSnLWREFvRTqy qVjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=0Lmc+56IHmNUVV595kPIF7JpmQqkE6f9UWVT+HLFZQo=; b=deNPo4sLGT4Vgd+mSgtmMxxWScWH2c5sTh4bP6VoaeubMrYC7Agr/q+VE3BBAah6bG xOx+rW02GNIPJJr+gPaNkkIhTwxXEcbyBMCl9S3WNAyPMqYFOa3PYH21llOXrAUl3MCF EmE9clFuK53K/lu9kx1G/rt7cLMoRZkP/gDNaAod/Xwz9i2kG9c0S9v3rpCndq4j99Yr co2/u2PRZzPy9SFHJ1W4OjoeMnbG2ObUQbNk40RHovhBQjXDWQEAqSx98AL0XwhmaH+6 WMmDVrpiYH3TNyXi0CT6rum09gS9A0Vd0mvMunt+txz6e9Na6wfS93KMb4bHoX6elS1c fqOQ== 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 p14si12752177ota.71.2020.01.16.04.25.40; Thu, 16 Jan 2020 04:25:52 -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 S1726343AbgAPMYo (ORCPT + 99 others); Thu, 16 Jan 2020 07:24:44 -0500 Received: from foss.arm.com ([217.140.110.172]:48556 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726018AbgAPMYo (ORCPT ); Thu, 16 Jan 2020 07:24:44 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 75F851396; Thu, 16 Jan 2020 04:24:43 -0800 (PST) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F7733F534; Thu, 16 Jan 2020 04:24:42 -0800 (PST) Date: Thu, 16 Jan 2020 12:24:31 +0000 From: Sudeep Holla To: Zeng Tao Cc: linuxarm@huawei.com, Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] cpu-topology: Skip the exist but not possible cpu nodes Message-ID: <20200116122420.GA40666@bogus> References: <1579139255-29262-1-git-send-email-prime.zeng@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1579139255-29262-1-git-send-email-prime.zeng@hisilicon.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry for being pedantic and not mentioning this earlier. Can you improve the $subject. I prefer: cpu-topology: Don't error on more than CONFIG_NR_CPUS CPUs in device tree On Thu, Jan 16, 2020 at 09:47:35AM +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. > Also the commit log to be: " When the kernel is configured with CONFIG_NR_CPUS smaller than the number of CPU nodes in the device tree(DT), all the CPU nodes parsing done to fetch topology information will fail. This is not reasonable as it is legal to have all the physical CPUs in the system in the DT. Let us just skip such CPU DT nodes that are not used in the kernel rather than returning an error. " > Signed-off-by: Zeng Tao > --- > Changelog: > v2->v3: > -Fix the Review comments by sudeep, including fix typo, remove redundant check > logic, change the warning print level etc. > 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 | 20 +++++++++++++++----- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 5fe44b3..d4302a1 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -248,6 +248,16 @@ 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 basically three kinds of return values: > + * (1) logic cpu number which is > 0. > + * (2) -ENODEV 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. I prefer (2) to be reword as below: " -ENODEV when the device tree(DT) node is valid and found in the DT but there is no possible logical CPU in the kernel to match. This happens when CONFIG_NR_CPUS is configure to be smaller than the number of CPU nodes in DT. We need to just ignore this case. " With all these changes you can stick: Reviewed-by: Sudeep Holla -- Regards, Sudeep