Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3532952pxp; Tue, 8 Mar 2022 16:48:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJxg3xeIBIMyJ/hy/CjV0j8Ctm+F6gALTHssOYQqf5SXcwh7Iza0QYpBzRIagBA8TWRhAz1p X-Received: by 2002:a17:902:f681:b0:151:d88b:ebde with SMTP id l1-20020a170902f68100b00151d88bebdemr17325407plg.159.1646786913669; Tue, 08 Mar 2022 16:48:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646786913; cv=none; d=google.com; s=arc-20160816; b=Ku2H8HrNXdb1WqH/+yrtYqqR5j20WnnYMmOf1vIfkicTKfti8tnM6b/pnUuz0DURjC QgRuw0IcDysY9n/U+2/HBj4pxvF1n1EaOVyOOe/k12P0tLDVORe8VFzVLapjj+ApW3bE NyMOXgtoTHe8i/SR+CrP1nNIKMZ++JTK/nxik8ODiVOy71Wka+clvCTi9OY5IIWsRoa/ 3KQCEwsT98AdIzhobBnOwItIQ3Ff2EgBT3YdrxrJcjTlNeroKcc9sv/+JK8i9VWYS0Hx Mp/bSnvrOQkDDKTlo0+f9iVvHw5dstQjp2PDrKDPQXE/8HQxEljQY5wVOhb2T84tgHpF QPhA== 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=97ow0WRrE+vLBLgMBIuJUfOwgNIpy23XviQZ6UmnYZc=; b=MnqlvvshZ0avzKEMgouCQi9NdAIPixt/QfgkLvsJDSU0bY2bw/9utkCf51ySGsU3Dk 2u1FG+kGsnn5SNOX82802YUIcAlVM6FfwlRZOiYc8mCEs6HohHdldWHuBuVo7iASzc1r doImH57YI320jwVHnS7IfSmOsi5XNidulCJhZ3HB3vLT1aWAcQSeFRx5qhGA5a086HSM LGjf3TrnqKop7wcPnhRJEJLWRe8Uk15ukQZqRKx1+twHs74hxARlsClY62P+tlrUJneH RQ81azxUdA7uF1vXWkzAJ7JYru442zt19+29yHUiqpc1kOvmIYgaE3GVvnJ+VvwOoTtm dRWQ== 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 b4-20020a170903228400b00151f12d9739si505310plh.96.2022.03.08.16.48.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 16:48:33 -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 1297F142342; Tue, 8 Mar 2022 16:00:45 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348867AbiCHRTg (ORCPT + 99 others); Tue, 8 Mar 2022 12:19:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348777AbiCHRTM (ORCPT ); Tue, 8 Mar 2022 12:19:12 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 222BF1EEC1 for ; Tue, 8 Mar 2022 09:18:14 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AEBC060C82 for ; Tue, 8 Mar 2022 17:18:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BE2EC340EB; Tue, 8 Mar 2022 17:18:11 +0000 (UTC) Date: Tue, 8 Mar 2022 17:18:07 +0000 From: Catalin Marinas To: Robin Murphy Cc: Arnd Bergmann , Marc Zyngier , Rongwei Wang , Will Deacon , joey.gouly@arm.com, Mark Rutland , Andrew Morton , Linux ARM , Linux Kernel Mailing List Subject: Re: [PATCH RFC] arm64: improve display about CPU architecture in cpuinfo Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9296f97c-f894-001c-53e6-41bbfe36ce71@arm.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 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 :) You can get the MIDR from /sys/devices/system/cpu/cpu*/regs/identification/midr_el1. As for printing the actual names, we thought we'd leave it to tools like lscpu. I'm not keen on maintaining a dictionary of MIDR to CPU marketing names in the kernel, deal with rebranding and so on. For x86 you can get the name from the CPU itself IIUC, that's not the case for arm. -- Catalin