Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3536792pxp; Tue, 8 Mar 2022 16:54:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzvjtNFp7WDICFCkz6KttKWkVjC662OJ/Au+k4QVw+Txf3fVT7zKXZl1ehhb8SBSfTEaT6Z X-Received: by 2002:a17:90a:7d17:b0:1bd:6972:f942 with SMTP id g23-20020a17090a7d1700b001bd6972f942mr7728273pjl.160.1646787286119; Tue, 08 Mar 2022 16:54:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646787286; cv=none; d=google.com; s=arc-20160816; b=zgbDITyb/CdM1LgQ+nl2sEMJ1vU9jv48FpuUC3t3gIweFAsnWxTa2ra+kbZF1Cewy6 o+U20lxMU3tMRjcfxUR2NnXk/mHnVmqhXHLe3tMRRaa3tpTO1MrfjBeSA3LSaoPNpxLG jItfCMgIpjj/OIn5usY4nf+PHXEftGKAu/ic4SSMzopEVEPikobGnciIuEnngdNPldtt wwU93K+1ENcvHN1RNYGTue+rWDDn7QhGD/Lv64C+o/+Wk1qyTfK8G8fsUzx78hlociVW ppLii1vwS3/u3LbRX7Z4zDDTtI3T0t/T7BWuDbc1M62sgMEhwC3a2NjzjectlmohllkJ Q9Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=rbHSbzq3MR2/PbszuCT/m+f6VquqvPt4RtpTNk41MAE=; b=OPTwrgYyTEI0mkf+OM1IuOSd/+cWuyUxyJVNabuvQsw1gI+e2v6S8zGhVpt6fd3uPG lPk3egkWQHldYgRfvVWTXK5R/ycYO7xrN8wXjVqh57dFVUkPC5q0AbQJfcGI+hC5T2yq KLblAJpbPERDkLKbYtuibgG//zVgQD1E2pOLKkiiXiG5r4xbrSDxv8Hz7PYuKY0fEc0l UDSIrBn3bAlRzss5ka21w6w4JNzTaUQANkKuA/oSrGoQXOjNFzarCV5nFXh3FoC4nTfA p0yNDkoPAcCuyeS/lXqLsP6iZhRl7wuuqugDvp2PumMJ4iKwwM5vtGSqvx+E1/SIoWlz YEtQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id c7-20020a654207000000b00378ef4d76f4si392581pgq.492.2022.03.08.16.54.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 16:54:46 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 59EF7155C02; Tue, 8 Mar 2022 16:04:42 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349929AbiCHTKh (ORCPT + 99 others); Tue, 8 Mar 2022 14:10:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349886AbiCHTKT (ORCPT ); Tue, 8 Mar 2022 14:10:19 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A595649276 for ; Tue, 8 Mar 2022 11:09:21 -0800 (PST) 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 6C69A1516; Tue, 8 Mar 2022 11:09:21 -0800 (PST) Received: from [10.57.41.254] (unknown [10.57.41.254]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 931F93FA45; Tue, 8 Mar 2022 11:09:19 -0800 (PST) Message-ID: <1dcfc5a8-e344-0bf2-95ea-862aac747b92@arm.com> Date: Tue, 8 Mar 2022 19:09:14 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH RFC] arm64: improve display about CPU architecture in cpuinfo Content-Language: en-GB To: "Russell King (Oracle)" Cc: Arnd Bergmann , Marc Zyngier , Rongwei Wang , Catalin Marinas , Will Deacon , joey.gouly@arm.com, Mark Rutland , Andrew Morton , Linux ARM , Linux Kernel Mailing List References: <20220307030417.22974-1-rongwei.wang@linux.alibaba.com> <87h78a178u.wl-maz@kernel.org> <87bkyi0x53.wl-maz@kernel.org> <1b94af8b-a294-5765-4e1e-896f70db621f@arm.com> <9296f97c-f894-001c-53e6-41bbfe36ce71@arm.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-03-08 17:57, Russell King (Oracle) wrote: > On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote: >> On 2022-03-07 19:30, Arnd Bergmann wrote: >>> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy wrote: >>> >>>> And arguably it's not even too late, because 10 years ago this *did* say >>>> "AArch64". I don't remember all the exact details behind commit >>>> 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough >>>> of a memory to go and look up the git history - but I don't think we >>>> changed any of those fields without a real reason. >>>> >>> >>> The patch description does state that this was done for compatibility with >>> 32-bit architectures, which does make some sense. I suppose for similar >>> reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at >>> 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode. >>> >>> The part that I find more annoying is how we leave out the one bit >>> of information that people are generally looking for in /proc/cpuinfo: >>> the name of the processor. Even though we already know the >>> exact processor type in order to handle the CPU errata, this is >>> always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit, >>> and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit, >>> with the revision being the least important bit of information here... >> >> Eh, it's hardly impossible to recompose a MIDR value from the implementer, >> part, variant and revision fields if one actually needs to. Maybe we could >> null-terminate the raw MIDR value and print it as a string of >> largely-unprintable characters in the "model name" field... I guess that >> might satisfy the crowd who want parity* with x86 CPUID, at least :) > > Actually, it is impossible to do it reliably. I won't expand on this, > except what I said in my other reply - there are cases where the MIDR > value is not unique. Sorry, I was assuming the given context of CPUs which report as v7 or v8, where one can safely and unambiguously infer that the missing original MIDR.Architecture value was 0xf. No implication was intended that it was possible for everything in general. Robin.