Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1153745pxu; Fri, 27 Nov 2020 00:37:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJwnJ378hTtfXj6tFgYb4CYoYYOS1IqgoQZ0taazafdM/ATKvZa8S9xOueXHIVOpn5dlcX/g X-Received: by 2002:a17:906:4104:: with SMTP id j4mr6619747ejk.439.1606466227538; Fri, 27 Nov 2020 00:37:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606466227; cv=none; d=google.com; s=arc-20160816; b=gzR9I9ibnVJ6tpvdKPAy/L3wsFH3hYEzthyKcBkLa35+l5V159FpTSx5KAnW+bMv9e EGRgdMkT8CjTGJJ1dosOnaVDgC/ockrd3HvgqqElu8m8E8s4RrsxmGNQjpUIcEsCCCyT BdrQrT61MGJX7hSOLQsfmpZWEBB4vwRdMrgLiHe70UoVmn34UpRRbqSofnU0nPGIH6Qo jpRoaIXmipUFW2u9+BFXjiNMAJ5Wk038RmiIlqgtDzSI4X27wkXe32m2KDkXdWrVx6JK PHotHXm/96tJ+IO69LqTo7b0wYc7t2Q41Cm5zOk6atav41FrQ6t0rF21Gx9gJpM5zfCE A4dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=7bw3W/7WwjcQo5kCF0DXcfyp3QYENzfXDuIcBIrZ644=; b=jKsDwbTpkP4S0EfAS9bCp/IegDSJVtnUQNRRfoFlKzYxvYxFsjKMlcDpKRpE8qNqkW YwqJYT/vCVSu5kwjlFL384d1braISwBNAQz0FSkiVwabaJ9XYBgwASKtbq2wA3DOQDtp HTbLOG4s3uAc+aPSe7PalufjWuOKD+yGjqHYNXxLfHrR2wNsnp6EFHXuFx6PVNExCYdD dmmwJWPsrEE4yPOpCDrF9zM65AZzmYd7ieUVZXkLVpgsPE9O3LHV+WbeP86iKJRPqYMO mo+IR2cpUZYa4APuu4F+lY9DNCCqZIjj4eY0gVrfrqELfVWjEf9f4GwPJ5uX8UvQj3XR N/Gw== 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=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o27si4795175edz.209.2020.11.27.00.36.45; Fri, 27 Nov 2020 00:37:07 -0800 (PST) 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=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404373AbgKZR2p (ORCPT + 99 others); Thu, 26 Nov 2020 12:28:45 -0500 Received: from foss.arm.com ([217.140.110.172]:41384 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404312AbgKZR2p (ORCPT ); Thu, 26 Nov 2020 12:28:45 -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 8BE7331B; Thu, 26 Nov 2020 09:28:44 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.30.234]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EA92C3F23F; Thu, 26 Nov 2020 09:28:40 -0800 (PST) Date: Thu, 26 Nov 2020 17:28:38 +0000 From: Mark Rutland To: David Brazdil Cc: kvmarm@lists.cs.columbia.edu, Jonathan Corbet , Catalin Marinas , Will Deacon , Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , Dennis Zhou , Tejun Heo , Christoph Lameter , Lorenzo Pieralisi , Sudeep Holla , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com Subject: Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int Message-ID: <20201126172838.GD38486@C02TD0UTHF1T.local> References: <20201126155421.14901-1-dbrazdil@google.com> <20201126155421.14901-4-dbrazdil@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201126155421.14901-4-dbrazdil@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote: > CPU index should never be negative. Change the signature of > (set_)cpu_logical_map to take an unsigned int. > > Signed-off-by: David Brazdil Is there a function problem here, or is this just cleanup from inspection? Core code including the cpuhp_*() callbacks uses an int, so if there's a strong justification to change this, it suggests there's some treewide cleanup that should be done. I don't have strong feelings on the matter, but I'd like to understand the rationale. Thanks, Mark. > --- > arch/arm64/include/asm/smp.h | 4 ++-- > arch/arm64/kernel/setup.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h > index 2e7f529ec5a6..bcb01ca15325 100644 > --- a/arch/arm64/include/asm/smp.h > +++ b/arch/arm64/include/asm/smp.h > @@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number); > * Logical CPU mapping. > */ > extern u64 __cpu_logical_map[NR_CPUS]; > -extern u64 cpu_logical_map(int cpu); > +extern u64 cpu_logical_map(unsigned int cpu); > > -static inline void set_cpu_logical_map(int cpu, u64 hwid) > +static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid) > { > __cpu_logical_map[cpu] = hwid; > } > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index 133257ffd859..2f2973bc67c7 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions); > > u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID }; > > -u64 cpu_logical_map(int cpu) > +u64 cpu_logical_map(unsigned int cpu) > { > return __cpu_logical_map[cpu]; > } > -- > 2.29.2.454.gaff20da3a2-goog >