From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92504C388F9 for ; Wed, 21 Oct 2020 13:19:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1561E221FC for ; Wed, 21 Oct 2020 13:19:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RYbeLUWy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1561E221FC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=srddVPFjCA4PMxgV4Tkrndi2XutDjmvjRpcxY5wjqPY=; b=RYbeLUWy+zM8eGckNViboCNSV f/oTe8MOI0qvEarYErEA7P4Lx9sxeN+yhTTn7byD0UI3JjSQyPNOryKWdXk0MUzj6H3ntgduhUqIj +YEz1iHJxCCGZEE/QHFJLSTBUkoT/9qMa7k0gqHh2BbL2DKvCEld3zxx2+BaIrgM1SnLNj6E88Z0y Yx2TYRQfEgFHI/ouLUpJgvOLJPl625v+d5fPrEZH8N74GEhfCMxH8ZoBqKXN2j2BPJJOOyL7BWSxN vckVEUMT2soOZywayQrfjk7SpHwp0WQTBRj+h9wB0Jj7mbwxWltCkltio5ux40m5oc3g9fCUPPeMc X9vs09iyw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVE0O-0004GC-Ul; Wed, 21 Oct 2020 13:18:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVE0M-0004F5-6G for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 13:18:15 +0000 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 878BE31B; Wed, 21 Oct 2020 06:18:13 -0700 (PDT) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 334AC3F66B; Wed, 21 Oct 2020 06:18:12 -0700 (PDT) Date: Wed, 21 Oct 2020 14:18:09 +0100 From: Qais Yousef To: Marc Zyngier Subject: Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs Message-ID: <20201021131809.icoxcu2ngzcznw2d@e107158-lin> References: <20201021104611.2744565-1-qais.yousef@arm.com> <20201021104611.2744565-5-qais.yousef@arm.com> <63fead90e91e08a1b173792b06995765@kernel.org> <20201021112519.GA1141598@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201021_091814_299039_D7EDDADB X-CRM114-Status: GOOD ( 27.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Will Deacon , "Peter Zijlstra \(Intel\)" , Greg Kroah-Hartman , James Morse , Catalin Marinas , Linus Torvalds , Morten Rasmussen , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10/21/20 12:46, Marc Zyngier wrote: > On 2020-10-21 12:25, Greg Kroah-Hartman wrote: > > On Wed, Oct 21, 2020 at 12:09:58PM +0100, Marc Zyngier wrote: > > > On 2020-10-21 11:46, Qais Yousef wrote: > > > > So that userspace can detect if the cpu has aarch32 support at EL0. > > > > > > > > CPUREGS_ATTR_RO() was renamed to CPUREGS_RAW_ATTR_RO() to better reflect > > > > what it does. And fixed to accept both u64 and u32 without causing the > > > > printf to print out a warning about mismatched type. This was caught > > > > while testing to check the new CPUREGS_USER_ATTR_RO(). > > > > > > > > The new CPUREGS_USER_ATTR_RO() exports a Sanitised or RAW sys_reg based > > > > on a @cond to user space. The exported fields match the definition in > > > > arm64_ftr_reg so that the content of a register exported via MRS and > > > > sysfs are kept cohesive. > > > > > > > > The @cond in our case is that the system is asymmetric aarch32 and the > > > > controlling sysctl.enable_asym_32bit is enabled. > > > > > > > > Update Documentation/arm64/cpu-feature-registers.rst to reflect the > > > > newly visible EL0 field in ID_AA64FPR0_EL1. > > > > > > > > Note that the MRS interface will still return the sanitized content > > > > _only_. > > > > > > > > Signed-off-by: Qais Yousef > > > > --- > > > > > > > > Example output. I was surprised that the 2nd field (bits[7:4]) is > > > > printed out > > > > although it's set as FTR_HIDDEN. > > > > > > > > # cat /sys/devices/system/cpu/cpu*/regs/identification/id_aa64pfr0 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > > > > > # echo 1 > /proc/sys/kernel/enable_asym_32bit > > > > > > > > # cat /sys/devices/system/cpu/cpu*/regs/identification/id_aa64pfr0 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > 0x0000000000000012 > > > > 0x0000000000000012 > > > > 0x0000000000000011 > > > > 0x0000000000000011 > > > > > > This looks like a terrible userspace interface. > > > > It's also not allowed, sorry. sysfs is "one value per file", which is > > NOT what is happening at all. > > I *think* Qais got that part right, though it is hard to tell without > knowing how many CPUs this system has (cpu/cpu* is ambiguous). Correct. This interface already exists for other registers and reads a single value for each CPU. I just added the ability to read a new register. Though it has a slightly different behavior: reads Sanitized vs RAW info. Thanks -- Qais Yousef _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel