Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751867AbaG1SvJ (ORCPT ); Mon, 28 Jul 2014 14:51:09 -0400 Received: from service87.mimecast.com ([91.220.42.44]:38222 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751742AbaG1SvD convert rfc822-to-8bit (ORCPT ); Mon, 28 Jul 2014 14:51:03 -0400 Message-ID: <53D69BB3.8040106@arm.com> Date: Mon, 28 Jul 2014 19:51:31 +0100 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hanjun Guo , Catalin Marinas , "Rafael J. Wysocki" , Mark Rutland CC: Sudeep Holla , "graeme.gregory@linaro.org" , Arnd Bergmann , "grant.likely@linaro.org" , Will Deacon , Jason Cooper , Marc Zyngier , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles Garcia-Tobin , "linux-acpi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <1406206825-15590-5-git-send-email-hanjun.guo@linaro.org> In-Reply-To: <1406206825-15590-5-git-send-email-hanjun.guo@linaro.org> X-OriginalArrivalTime: 28 Jul 2014 18:51:00.0963 (UTC) FILETIME=[E027F330:01CFAA94] X-MC-Unique: 114072819510103901 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/07/14 14:00, Hanjun Guo wrote: > arch_fix_phys_package_id() will be called in ACPI core to use > the slot number provided by ACPI to update the physical package > id, then we can get the right value in the "physical id" field > of /proc/cpuinfo. > > Signed-off-by: Hanjun Guo > --- > arch/arm64/include/asm/topology.h | 2 ++ > arch/arm64/kernel/topology.c | 14 ++++++++++++++ > 2 files changed, 16 insertions(+) > > diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h > index 7ebcd31..2b216d4 100644 > --- a/arch/arm64/include/asm/topology.h > +++ b/arch/arm64/include/asm/topology.h > @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS]; > void init_cpu_topology(void); > void store_cpu_topology(unsigned int cpuid); > const struct cpumask *cpu_coregroup_mask(int cpu); > +void arch_fix_phys_package_id(int num, u32 slot); > > #else > > static inline void init_cpu_topology(void) { } > static inline void store_cpu_topology(unsigned int cpuid) { } > +static inline void arch_fix_phys_package_id(int num, u32 slot) { } > > #endif > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c > index 43514f9..c547885 100644 > --- a/arch/arm64/kernel/topology.c > +++ b/arch/arm64/kernel/topology.c > @@ -281,3 +281,17 @@ void __init init_cpu_topology(void) > if (parse_dt_topology()) > reset_cpu_topology(); > } > + > +/* > + * Use the CPU slot number provided by ACPI to update the physical > + * package id when cpuid_topo->cluster_id is not available, then we > + * can get the right value in the "physical id" field of /proc/cpuinfo. > + */ We don't have "physical id" field in /proc/cpuinfo on ARM64. > +void arch_fix_phys_package_id(int num, u32 slot) > +{ > + struct cpu_topology *cpuid_topo = &cpu_topology[num]; > + > + if (cpuid_topo->cluster_id == -1) > + cpuid_topo->cluster_id = slot; > +} > +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id); > The ACPI core uses this function to set the package id as read from _SUN from the device. As per spec, _SUN is used by OSPM UI to identify slots for the user. Do we know how will this be used on ARM64 ? If not clear at this time, better to define it or keep it empty. I see even x86 does nothing in that function. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/