Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2283702yba; Mon, 15 Apr 2019 08:32:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+nRxz41bVY3hkU+2R19+McAH9Dopj0OYXW2Y+IZA8nOnWaUxHb6IFaAEbDUGyeVD6JgCU X-Received: by 2002:a63:df12:: with SMTP id u18mr71234394pgg.135.1555342375350; Mon, 15 Apr 2019 08:32:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555342375; cv=none; d=google.com; s=arc-20160816; b=0KflMHVOciwwAbTO2bwuCmiecNmUPfJW/qpSqywTQBUAlh8SvRCUvONFrb+STfMpUC OQ27p7JkbDOSijZgWaCmRPbVLc1/wwfH3jl08Pmax+9YucPW1/n72EAkj1FzsRqumXhZ xJNwZCQWyKxxaUFv+02za2lGKE14awcwg8Rv/Bz5+wvrzi5W9qkpC2Uey+cPI6SfM0+m 8TLWm2Xjef1N35oOwP9QZwZxmnVsL2iUV1bQOmQCL99BAcSwr/l5oGIOJGMe2hJ2sLDo 1VHtGwGUUZY019C3v/wHUecB46/fj22X2rpxbcRWSnbhi7+gvfn+fk04M9q0YCh75d/i oN2A== 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=1SPS27o2jUcSktTiIxvJHq+kozxBkDe7xk3zSdL41XU=; b=hClW9mJqqGLYES3YXf8uFO483O778b0Lo4aKmntK2l8qNfyP/4JEuHF0w9NVEuoLfL t54yzajUM5YSKkAn2OyjBFWzbRpXAjxbXRHAoIxPQt7wZH90QP/YUZXaPIqLqMuHl5JO K3le4ywxqJpPxurLWAMT8mX0CEO1WExLyB8AJtOFQ99uDGMD1raGBH6O6gU7o9Qw3Io8 BuOm6/MXjyhzKiuAyH4nXRTjGn2hxHp1WZZ4KveLB+A6wKguVhPOsP8OqzM9LwkaxwFR 7dvNhzfkSrOs34ILFiHwIUFwiEJY56ptAgRXz5XbYl1umyTPuKeYK7tBBP3poxdw9fGO snnw== 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 l184si28999192pge.425.2019.04.15.08.32.38; Mon, 15 Apr 2019 08:32:55 -0700 (PDT) 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 S1727626AbfDOPby (ORCPT + 99 others); Mon, 15 Apr 2019 11:31:54 -0400 Received: from foss.arm.com ([217.140.101.70]:37142 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726034AbfDOPbx (ORCPT ); Mon, 15 Apr 2019 11:31:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9D08B374; Mon, 15 Apr 2019 08:31:53 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1BC6F3F68F; Mon, 15 Apr 2019 08:31:49 -0700 (PDT) Date: Mon, 15 Apr 2019 16:31:47 +0100 From: Sudeep Holla To: Atish Patra Cc: linux-kernel@vger.kernel.org, Albert Ou , Anup Patel , Ard Biesheuvel , Catalin Marinas , devicetree@vger.kernel.org, Dmitriy Cherkasov , Greg Kroah-Hartman , Ingo Molnar , Jeremy Linton , Johan Hovold , linux-riscv@lists.infradead.org, Mark Rutland , Morten Rasmussen , Otto Sabart , Palmer Dabbelt , Paul Walmsley , "Peter Zijlstra (Intel)" , "Rafael J. Wysocki" , Rob Herring , Will Deacon Subject: Re: [RFT/RFC PATCH v3 4/5] arm: Use common cpu_topology Message-ID: <20190415153147.GB28623@e107155-lin> References: <20190320234806.19748-1-atish.patra@wdc.com> <20190320234806.19748-5-atish.patra@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190320234806.19748-5-atish.patra@wdc.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 On Wed, Mar 20, 2019 at 04:48:05PM -0700, Atish Patra wrote: > Currently, ARM32 and ARM64 uses different data structures to > represent their cpu toplogies. Since, we are moving the ARM64 > topology to common code to be used by other architectures, we > can reuse that for ARM32 as well. > > Signed-off-by: Atish Patra > --- > arch/arm/include/asm/topology.h | 22 +--------------------- > arch/arm/kernel/topology.c | 10 +++++----- > include/linux/arch_topology.h | 10 +++++++++- > 3 files changed, 15 insertions(+), 27 deletions(-) > [...] > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h > index d4e76e0a..7c850611 100644 > --- a/include/linux/arch_topology.h > +++ b/include/linux/arch_topology.h > @@ -36,17 +36,25 @@ unsigned long topology_get_freq_scale(int cpu) > struct cpu_topology { > int thread_id; > int core_id; > +#ifdef CONFIG_ARM_CPU_TOPOLOGY > + int socket_id; Sorry, but I can't find any reason why we need to do this ifdef dance here, especially for socket_id vs package_id ? Other's I can understand as there are new, but I am sure we can find a way and get away with #ifdefery here completely. > +#else > int package_id; > int llc_id; > + cpumask_t llc_sibling; > +#endif > cpumask_t thread_sibling; > cpumask_t core_sibling; > - cpumask_t llc_sibling; > }; > > #ifdef CONFIG_GENERIC_ARCH_TOPOLOGY > extern struct cpu_topology cpu_topology[NR_CPUS]; > > +#ifdef CONFIG_ARM_CPU_TOPOLOGY > +#define topology_physical_package_id(cpu) (cpu_topology[cpu].socket_id) > +#else > #define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id) > +#endif Since all callsites must use topology_physical_package_id, we should be able to rename socket_id to package_id easily. -- Regards, Sudeep