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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A0428C433EF for ; Fri, 10 Dec 2021 10:43:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=FVmL027xlue1oYUzy3Uh43sRmBtJa0y7rSeP+ggqu94=; b=r6OJMv5akGaePF 8AFyMAxnp4BQ6uw5cUEg0GXZ+IpgX+A2rvIKOete6WKFlkVqqmpmnqBD2m8a9ySq5AxNa4Fp60OMa 80TqUcNy7bJZaWTD6C0u/V27QnBvjGRJwtRN3eGC68+FksHmsIRfPxdSdWtFLWWT2V2wX692IhrKu U06iYnI39T53sng1XNjtM/nSb3YIqVNoKM/fXB0xfPrN+2tEqigJaCPuy11A+v6h+lytonZPOZSxG +gnx90Gx5XaQRcXBCPGr0gSBwvHGH7KR1C9v57AgAT63COcwJWs72vkHKAwAvupMZwcnPVSoaliEy q4DWtzjuXsWYzzKOUUKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mvdLG-001WME-O4; Fri, 10 Dec 2021 10:41:30 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mvdLD-001WLd-27 for linux-arm-kernel@lists.infradead.org; Fri, 10 Dec 2021 10:41:28 +0000 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 ams.source.kernel.org (Postfix) with ESMTPS id B5522B82763; Fri, 10 Dec 2021 10:41:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F408C00446; Fri, 10 Dec 2021 10:41:22 +0000 (UTC) Date: Fri, 10 Dec 2021 10:41:18 +0000 From: Catalin Marinas To: Mark Brown Cc: Will Deacon , Shuah Khan , Shuah Khan , Alan Hayward , Luis Machado , Salil Akerkar , Basant Kumar Dwivedi , Szabolcs Nagy , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v6 13/37] arm64/sme: Basic enumeration support Message-ID: References: <20211115152835.3212149-1-broonie@kernel.org> <20211115152835.3212149-14-broonie@kernel.org> 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-20211210_024127_270896_7D7B6230 X-CRM114-Status: GOOD ( 27.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Thu, Dec 09, 2021 at 07:28:16PM +0000, Mark Brown wrote: > On Thu, Dec 09, 2021 at 06:41:26PM +0000, Catalin Marinas wrote: > > On Mon, Nov 15, 2021 at 03:28:11PM +0000, Mark Brown wrote: > > > +#define HWCAP2_SME (1 << 20) > > > +#define HWCAP2_SME_I16I64 (1 << 21) > > > +#define HWCAP2_SME_F64F64 (1 << 22) > > > +#define HWCAP2_SME_I8I32 (1 << 23) > > > +#define HWCAP2_SME_F16F32 (1 << 24) > > > +#define HWCAP2_SME_B16F32 (1 << 25) > > > +#define HWCAP2_SME_F32F32 (1 << 26) > > > +#define HWCAP2_SME_FA64 (1 << 27) > > > At this pace we'll need HWCAP3 pretty soon (since we only allocated > > 32-bit in each). I wonder whether we could instead not bother at all and > > just provide user-space emulation for ID_AA64SMFR0_EL1. > > I think so if people are willing to go along with just having userspace > check the ID register (IIRC access to it already does the right thing > but I need to confirm). We'll also need to think about how we handle > any new SVE features, that's got a similar thing going on and is most of > the existing usage of HWCAP2. It would be good to get feedback from the libc people. IIRC the ifunc resolver relies currently on the HWCAP bits. Could this be adapted to use the MRS instruction? We'd still keep the main HWCAP2_SME but without the finer-grained bits. The other option is to start going into the upper 32-bit of the elf_hwcap. We tried to avoid this some time back when we were still having doubts about merging ILP32. > > > + { > > > + .desc = "FA64", > > > + .type = ARM64_CPUCAP_SYSTEM_FEATURE, > > > + .capability = ARM64_SME_FA64, > > > + .sys_reg = SYS_ID_AA64SMFR0_EL1, > > > + .sign = FTR_UNSIGNED, > > > + .field_pos = ID_AA64SMFR0_FA64_SHIFT, > > > + .min_field_value = ID_AA64SMFR0_FA64, > > > + .matches = has_feature_flag, > > > + .cpu_enable = fa64_kernel_enable, > > > + }, > > > I'll comment here rather than the patch introducing has_feature_flag(): > > an alternative would be to add a .field_width option and in > > feature_matches() use cpuid_feature_extract_field_width() directly. All > > the arm64_ftr_bits entries already have a width, so just generalise it > > for arm64_cpu_capabilities. > > Sure, if people are happy with that - it's a more invasive change since > we don't currently set the widths, I wasn't clear if that was a case of > not needing it right now or a design decision. We didn't have a field_width since they were all 4 bits until SVE. If you don't want to touch all the entries in the array, we can say that a 0 value (i.e. not explicitly initialised) means default 4 and update it during init_cpu_features(). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel