Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2514289pxp; Mon, 7 Mar 2022 17:36:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJypnyibqafGLKK5xnD1obn9hcSdXzxgYCbY3JEgYrOao4kpmTMDuRs9SzwqoAH1m5xft7e2 X-Received: by 2002:a17:906:d10c:b0:6cd:4aa2:cd62 with SMTP id b12-20020a170906d10c00b006cd4aa2cd62mr11455934ejz.229.1646703396139; Mon, 07 Mar 2022 17:36:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646703396; cv=none; d=google.com; s=arc-20160816; b=WeCU4zedknaiZifSdC+BKuRssxMPLJF2a42KV0QyxXV48s2ob380a8POMtPl9/aNTW IDA8UWwSF6/l17E7bLZu8SBTj3UbQZq4XT78UCJBBTJwxpY14j5ZXXQpjb9i+Gr4xvbH 4afI5P9knelW6OGMnaB8LPsOmp3oPmZ7zjTKaJn5UcYRjn9yo/PWcafYZu6AaBIinc/0 44hzHeMZ9XmABZ82xZe8kSfaJz671Hv0gZ5LxShQTr9mxHNiJuzzD6Bz4d+EG75vrQK9 jwI9Ez4AZURAHytBraVqWv8KyO15CjCXNm0Q4xBR7U4Y7Yd4SmxIfMYK5CjOuezNjxNA oxow== 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=nix3qx1JGweXYDjFk0mr1/PD1c0pwrFLQ/y0IiGvz5A=; b=ppmT7//wsC7XIofFTCrwUDsNJ8hvuRwcSVY28jha05I/ir+8asWUAw1TTcOe2Oe3E+ G/b45wlqW9cVaF2Z0pFvjxjpPMi8BKUYXhzPYdfn1fTAOYICgXOTAswmAzsyyny1lfLV 0yCm1fkWcpi0bn2D06IR9ZLm3XsJmSCSXo6twmy3gLIDlQ7b7wKBmccLaSZZN3+UNJNa QNIiYwTvW5pc7o8ny+6SVMGdv2znkLaN5fIh07LyB3ZvA8+bc+Ft5XdBZNRVQiV+JLly ynttvRKKRXiBgBpvfUFnO5QBZ6RkzJW7vNbLsQjMaYahcSQUF4oe62JcGkYnZWSBru/g yiSw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n5-20020a1709065e0500b006d6e925a24fsi8282394eju.902.2022.03.07.17.36.13; Mon, 07 Mar 2022 17:36:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241188AbiCGUGO (ORCPT + 99 others); Mon, 7 Mar 2022 15:06:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241848AbiCGUGL (ORCPT ); Mon, 7 Mar 2022 15:06:11 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DC013710EF for ; Mon, 7 Mar 2022 12:05:15 -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 61740153B; Mon, 7 Mar 2022 12:05:15 -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 CE4783FA35; Mon, 7 Mar 2022 12:05:13 -0800 (PST) Message-ID: <9296f97c-f894-001c-53e6-41bbfe36ce71@arm.com> Date: Mon, 7 Mar 2022 20:05:06 +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: Arnd Bergmann Cc: 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> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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-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 :) Robin. * Of course this is a complete lie, because every time that comes up it's always really about the microarchitecture (which Arm's CPU core marketing names represent), where x86 is perfectly on par with arm64 with its equivalently-inscrutable "cpu family" and "model" numbers, rather than cool microarchitecture names like "Sausage Lake" or whatever...