Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp250569pxk; Wed, 9 Sep 2020 04:37:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyteYrYJri4jSk6KFiGW4PekHZHj6CxhzqHuIyqSQRIqVQMvPp9qKKG2IYg+8gEddGX7F5n X-Received: by 2002:a05:6402:1151:: with SMTP id g17mr3672005edw.227.1599651420805; Wed, 09 Sep 2020 04:37:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599651420; cv=none; d=google.com; s=arc-20160816; b=WX+E+YVTsPSS/PjRvdhZMt56ZLqEC/IWoUdPf6+j1PkWtyWMAcNkpJxa9k/82+BbEg DbsGZUwY8ib7VSuPzw3ru0v2I92akM33jr3T+sudtz9mNVOumxWcxEB4+fammoKtnD/o kBCdInXFbLHgejHmfuc5iJmhpqcHGy2+aDGNQgsGgg9K0GuzRm0hpk+K1vZsnWhjLX3+ i9Bxlwdh0y4GljZgM4lDrmKwOMY5w9nLTePJrXsAedEMR2eLKms/2VdKpwnVZpza+dLu lBSltdJtN3nGkhoZe+qDcPzoKDGay+HvmjwxUxxMEPWJvBJehoHQq9LSrbFZPATjiLHX uagw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=UiOi66z0X02TYuw5vCwuNhuAZMVTwEpjT8ew5x4727g=; b=dmmeD5/+ayU4Hfb5D+kALocdMI39iRFYVXOruKF2ZelHZvitnqP5E4V1DizK4jSPvo Yn78/odtVYrS7mtrznXJpxjohrry4txoApZ+vldsM1y1en/egiezmB8FAU9xdkG6wZJp dsorvIWwQVMS8BBzBj67B9E0e+gYuzMjNvd3OWC7Q4O+zSow+aLp4S3IJQO/eVikFnPA riJWoirQDBNKc7N06cNzGOP/ypxTv6U4zF21QEDk91ykbBUanZzfEAOFT2PldcBilooW HsK9R1rDCBrg7+iqgV+E0n028Uj+IPBlresAjHSGStpHgjHq7i1eBkGiC8G0M/DS8YMj NyjA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a6si1370203edq.278.2020.09.09.04.36.37; Wed, 09 Sep 2020 04:37:00 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729305AbgIILeC (ORCPT + 99 others); Wed, 9 Sep 2020 07:34:02 -0400 Received: from foss.arm.com ([217.140.110.172]:41878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726883AbgIILaI (ORCPT ); Wed, 9 Sep 2020 07:30:08 -0400 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 B322B31B; Wed, 9 Sep 2020 04:21:09 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 627073F68F; Wed, 9 Sep 2020 04:21:08 -0700 (PDT) References: <20200829130016.26106-1-valentin.schneider@arm.com> <678F3D1BB717D949B966B68EAEB446ED482417F4@DGGEMM506-MBX.china.huawei.com> <678F3D1BB717D949B966B68EAEB446ED482431A1@DGGEMM506-MBX.china.huawei.com> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: "Zengtao \(B\)" Cc: "linux-kernel\@vger.kernel.org" , "linux-arm-kernel\@lists.infradead.org" , Catalin Marinas , Will Deacon , Sudeep Holla , Robin Murphy , Jeremy Linton , Dietmar Eggemann , Morten Rasmussen Subject: Re: [PATCH] arm64: topology: Stop using MPIDR for topology information In-reply-to: <678F3D1BB717D949B966B68EAEB446ED482431A1@DGGEMM506-MBX.china.huawei.com> Date: Wed, 09 Sep 2020 12:21:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/09/20 02:44, B wrote: >> -----Original Message----- >> From: Valentin Schneider [mailto:valentin.schneider@arm.com] >> On 02/09/20 04:24, B wrote: >> > I agree with your idea to remove the topology functionality of MPIDR , >> > but I think we need also consider ARM32 and GIC. >> > >> >> Could you please elaborate? This change doesn't impact arch_topology, so >> only arm64 is affected. > > Yes, this change only affects arm64, my question is that do we need to > leverage it to arm32 since arm32 got the same issue. > > And for GIC we are also using MPIDR for the topology info, but I am sure > It's got the same issue or not, just a suggestion to have a look. So technically yes, we can be bothered by this on arm32 - Sudeep pointed out a list of DT files that shows platforms with non-zero values in Aff1 or above. However, the bigger issue is that artificial separation in clusters of 16 CPUs due to extra limitations on Aff0 (mainly due to GICv3 AIUI). Given that GICv2 can support at most 8 CPU interfaces, I don't think we have it as bad on arm32.