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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3730C433F5 for ; Tue, 3 May 2022 23:21:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E68B86B0071; Tue, 3 May 2022 19:21:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E17546B0072; Tue, 3 May 2022 19:21:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D07336B0073; Tue, 3 May 2022 19:21:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C15346B0071 for ; Tue, 3 May 2022 19:21:30 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8EAFA29C1C for ; Tue, 3 May 2022 23:21:30 +0000 (UTC) X-FDA: 79426005540.15.E45D7D7 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by imf04.hostedemail.com (Postfix) with ESMTP id 08B1B40093 for ; Tue, 3 May 2022 23:21:22 +0000 (UTC) Received: from ip5b412258.dynamic.kabel-deutschland.de ([91.65.34.88] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nm1pd-0004Xd-6L; Wed, 04 May 2022 01:21:25 +0200 From: Heiko Stuebner To: Palmer Dabbelt , Paul Walmsley , Albert Ou , linux-riscv@lists.infradead.org Cc: Atish Patra , Anup Patel , Eric Biederman , Kees Cook , linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Michael Kerrisk , linux-man@vger.kernel.org, Jiatai He , "Hongren (Zenithal) Zheng" Subject: Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Date: Wed, 04 May 2022 01:21:23 +0200 Message-ID: <4734719.31r3eYUQgx@phil> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Authentication-Results: imf04.hostedemail.com; dkim=none; spf=none (imf04.hostedemail.com: domain of heiko@sntech.de has no SPF policy when checking 185.11.138.130) smtp.mailfrom=heiko@sntech.de; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 08B1B40093 X-Stat-Signature: 8y1ssotd5bfutny8bq98d88jpz3mswsz X-HE-Tag: 1651620082-882276 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Am Samstag, 30. April 2022, 15:50:22 CEST schrieb Hongren (Zenithal) Zheng: > This commit parses Zb/Zk related string from DT and > output them in cpuinfo > > One thing worth noting is that if DT provides zk, > all zbkb, zbkc, zbkx and zkn, zkr, zkt would be enabled. > > Note that zk is a valid extension name and the current > DT binding spec allows this. > > There currently lacks a mechanism to merge them when > producing cpuinfo. Namely if you provide a riscv,isa > "rv64imafdc_zk_zks", the cpuinfo output would be > "rv64imafdc_zbkb_zbkc_zbkx_zknd_zkne_zknh_zkr_zksed > _zksh_zkt" > > Tested-by: Jiatai He > Signed-off-by: Hongren (Zenithal) Zheng > --- > arch/riscv/include/asm/hwcap.h | 14 ++++++++++++++ > arch/riscv/kernel/cpu.c | 14 ++++++++++++++ > arch/riscv/kernel/cpufeature.c | 33 +++++++++++++++++++++++++++++++++ > 3 files changed, 61 insertions(+) > > diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h > index 0734e42f74f2..199eda39e0b8 100644 > --- a/arch/riscv/include/asm/hwcap.h > +++ b/arch/riscv/include/asm/hwcap.h > @@ -52,6 +52,20 @@ extern unsigned long elf_hwcap; > */ > enum riscv_isa_ext_id { > RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE, > + RISCV_ISA_EXT_ZBA, > + RISCV_ISA_EXT_ZBB, > + RISCV_ISA_EXT_ZBC, > + RISCV_ISA_EXT_ZBS, > + RISCV_ISA_EXT_ZBKB, > + RISCV_ISA_EXT_ZBKC, > + RISCV_ISA_EXT_ZBKX, > + RISCV_ISA_EXT_ZKNE, > + RISCV_ISA_EXT_ZKND, > + RISCV_ISA_EXT_ZKNH, > + RISCV_ISA_EXT_ZKSED, > + RISCV_ISA_EXT_ZKSH, > + RISCV_ISA_EXT_ZKR, > + RISCV_ISA_EXT_ZKT, > RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX, > }; > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > index ccb617791e56..7251336969c1 100644 > --- a/arch/riscv/kernel/cpu.c > +++ b/arch/riscv/kernel/cpu.c > @@ -87,6 +87,20 @@ int riscv_of_parent_hartid(struct device_node *node) > * extensions by an underscore. > */ > static struct riscv_isa_ext_data isa_ext_arr[] = { > + __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), > + __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), > + __RISCV_ISA_EXT_DATA(zbc, RISCV_ISA_EXT_ZBC), > + __RISCV_ISA_EXT_DATA(zbkb, RISCV_ISA_EXT_ZBKB), > + __RISCV_ISA_EXT_DATA(zbkc, RISCV_ISA_EXT_ZBKC), > + __RISCV_ISA_EXT_DATA(zbkx, RISCV_ISA_EXT_ZBKX), > + __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), > + __RISCV_ISA_EXT_DATA(zknd, RISCV_ISA_EXT_ZKND), > + __RISCV_ISA_EXT_DATA(zkne, RISCV_ISA_EXT_ZKNE), > + __RISCV_ISA_EXT_DATA(zknh, RISCV_ISA_EXT_ZKNH), > + __RISCV_ISA_EXT_DATA(zkr, RISCV_ISA_EXT_ZKR), > + __RISCV_ISA_EXT_DATA(zksed, RISCV_ISA_EXT_ZKSED), > + __RISCV_ISA_EXT_DATA(zksh, RISCV_ISA_EXT_ZKSH), > + __RISCV_ISA_EXT_DATA(zkt, RISCV_ISA_EXT_ZKT), > __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), I guess a bit of sorting rule might be helpful, here it's the additions above sscofpmf while in the enum it's the other way around. As the list will get a long longer over time, I guess consistency might improve readability. > __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), > }; > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index 1b2d42d7f589..10f9daf3734e 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -192,6 +192,39 @@ void __init riscv_fill_hwcap(void) > set_bit(*ext - 'a', this_isa); > } else { > SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); > + SET_ISA_EXT_MAP("zba" , RISCV_ISA_EXT_ZBA ); not sure if the additional whitespaces are really necessary? [especially the ones at the end] What did checkpatch have to say about them? > + SET_ISA_EXT_MAP("zbb" , RISCV_ISA_EXT_ZBB ); > + SET_ISA_EXT_MAP("zbc" , RISCV_ISA_EXT_ZBC ); > + SET_ISA_EXT_MAP("zbs" , RISCV_ISA_EXT_ZBS ); > + SET_ISA_EXT_MAP("zbkb" , RISCV_ISA_EXT_ZBKB ); > + SET_ISA_EXT_MAP("zbkc" , RISCV_ISA_EXT_ZBKC ); > + SET_ISA_EXT_MAP("zbks" , RISCV_ISA_EXT_ZBKX ); > + SET_ISA_EXT_MAP("zknd" , RISCV_ISA_EXT_ZKND ); > + SET_ISA_EXT_MAP("zkne" , RISCV_ISA_EXT_ZKNE ); > + SET_ISA_EXT_MAP("zknh" , RISCV_ISA_EXT_ZKNH ); > + SET_ISA_EXT_MAP("zksed" , RISCV_ISA_EXT_ZKSED ); > + SET_ISA_EXT_MAP("zksh" , RISCV_ISA_EXT_ZKSH ); > + SET_ISA_EXT_MAP("zkr" , RISCV_ISA_EXT_ZKR ); > + SET_ISA_EXT_MAP("zkt" , RISCV_ISA_EXT_ZKT ); > + SET_ISA_EXT_MAP("zkn" , RISCV_ISA_EXT_ZBKB ); > + SET_ISA_EXT_MAP("zkn" , RISCV_ISA_EXT_ZBKC ); > + SET_ISA_EXT_MAP("zkn" , RISCV_ISA_EXT_ZBKX ); > + SET_ISA_EXT_MAP("zkn" , RISCV_ISA_EXT_ZKND ); > + SET_ISA_EXT_MAP("zkn" , RISCV_ISA_EXT_ZKNE ); > + SET_ISA_EXT_MAP("zkn" , RISCV_ISA_EXT_ZKNH ); > + SET_ISA_EXT_MAP("zks" , RISCV_ISA_EXT_ZBKB ); > + SET_ISA_EXT_MAP("zks" , RISCV_ISA_EXT_ZBKC ); > + SET_ISA_EXT_MAP("zks" , RISCV_ISA_EXT_ZBKX ); > + SET_ISA_EXT_MAP("zks" , RISCV_ISA_EXT_ZKSED ); > + SET_ISA_EXT_MAP("zks" , RISCV_ISA_EXT_ZKSH ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZBKB ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZBKC ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZBKX ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZKND ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZKNE ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZKNH ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZKR ); > + SET_ISA_EXT_MAP("zk" , RISCV_ISA_EXT_ZKT ); > } > #undef SET_ISA_EXT_MAP > } >