Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3983330ybl; Mon, 9 Dec 2019 03:29:35 -0800 (PST) X-Google-Smtp-Source: APXvYqwuMFImegt0cTUQsYm0U4oFNp1AwcYdrahiiJFKD7XzH5Ec7vqfMbAvaF4EuG2CxnTZbOS2 X-Received: by 2002:aca:5785:: with SMTP id l127mr22914349oib.168.1575890975644; Mon, 09 Dec 2019 03:29:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575890975; cv=none; d=google.com; s=arc-20160816; b=craX4hAFDWICSJgI/PQeRytohtMYgKmhNEjkg/1B7YR46rki835mgC58KQMNEStIaQ /wNo9DZgScaR2zjcdVeGN25rlE3WxA59vXrmHUW4Sdg46JHrj5+dXFTw2iacYU394q/t lj5aNOUPMJBkbCDCZkdpDvU3MfdHEKIReBHKxX1Pu//dF+WqVx8sFjo7X3Ry/x6lX8IN nn3iH2fb2syr4FThJe55JlgXUIfz64yI4+QV9oWf4Gmm7smlpDHBEZeEfnfXcUDpdI2k 1gOKg9beqh1dL6I8cRTQP95mEBp2qFv3tulspY6PDCChrW1iAA72HEXx17tJbfRn3a28 Ld1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=kZ3daL4U0WYzjCH9CZXIcr9S8S7NTKX4dcW8m859Oao=; b=b1X87ShFq78bWvOewDCMPgUGtOxQQHGGFYA8LcI3SJV9WBLG89Jg1HhYPdzLc1X3kk Yuwv4oTVbclQHT1RJm1QQ+jLjBSfb2uHtM1qnmZ+Xe50WydIAXlHk6jaBj1TSZ7IgR4P 1Adyy/HZGEXwCDDuQXCcwsihcBsyLShEYJju0NaWzCs+AnF/wGNiV5euE2/Se6Dx6Uk3 BR3hj/kt+D+wTMDNRtMQilmS2ERcjdd4As6w0NNYeNkZ4LyytZrQQgnPHGjniS9jokkx BJd/vuF2ZnLBCTTdIUUY/xz++bLQTC8kNcPjTBoHNE2YvkAjFcyV/9S4FCHo6rFff3/8 0/Og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t10si11785483oif.255.2019.12.09.03.29.23; Mon, 09 Dec 2019 03:29:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727300AbfLIL2r (ORCPT + 99 others); Mon, 9 Dec 2019 06:28:47 -0500 Received: from mx2.suse.de ([195.135.220.15]:60682 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726377AbfLIL2q (ORCPT ); Mon, 9 Dec 2019 06:28:46 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E51C6B1A7; Mon, 9 Dec 2019 11:28:44 +0000 (UTC) From: Thomas Renninger To: Will Deacon , Felix Schnizlein Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, Felix Schnizlein , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, will.deacon@arm.com, x86@kernel.org Subject: Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64 Date: Mon, 09 Dec 2019 12:28:44 +0100 Message-ID: <25032400.G9DUGnJgnc@skinner.arch.suse.de> In-Reply-To: <20191209103110.GB3306@willie-the-truck> References: <20191206162421.15050-1-trenn@suse.de> <20191206162421.15050-4-trenn@suse.de> <20191209103110.GB3306@willie-the-truck> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote: > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote: > > From: Felix Schnizlein > > > > Export all information from /proc/cpuinfo to sysfs: > > implementer, architecture, variant, part, revision, > > bogomips and flags are exported. > > > > Example: > > /sys/devices/system/cpu/cpu1/info/:[0]# head * ... > > ==> flags <== > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm ... > I don't understand why we need this on arm64 The first intention of these patches is to port x86 /proc/cpuinfo. Because of the divergence of /proc/cpuinfo and the totally different info exported there across architectures, therefore it is also tried to get a unified interface across architectures where possible. So for flags and bugs this may work out, right? For the rest, it looks like people again only had their CPU in mind and exported to userspace what currently was needed... > and why it's an improvement > over all the other schemes we already support for identifying CPU features. Sigh... > Given the pain we've endured over the years exposing this sort of stuff to > userspace, I'm relucant to add more just for the fun of it. If there should ever be something like a string describing the CPU... In x86 it comes from the CPU itself. Maybe we get a model description at some point as well... Or any other entity which may also get exported on other archs.. Please remember this interface and watch out whether you could export things under the same name as done on other architectures. I'll revert everything but flags for ARM now. But this is the best example for the need of a generic interface: x86 - /proc/cpuinfo: flags : ... arm64 - /proc/cpuinfo: Features : ... even it is exactly the same kernel interface, even x86 flags are used according to arch/arm64/include/asm/cpufeature.h: * We use arm64_cpu_capabilities to represent system features, errata work But it is named differently in /proc/cpuinfo. This should not happen again in /sys/... Thomas