Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp342205iob; Tue, 3 May 2022 19:29:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvi6mZ2M9ZCX0gyDOYfyBAu/cQ71M0WzCPTd6QjRUDaaSuA6kijfXD/QfQ2BWebiBg1Fks X-Received: by 2002:a17:902:f254:b0:15e:b8c7:2a3e with SMTP id j20-20020a170902f25400b0015eb8c72a3emr5214045plc.100.1651631346356; Tue, 03 May 2022 19:29:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651631346; cv=none; d=google.com; s=arc-20160816; b=fuIRO+J1iL28OuPq6opnIPFqpp5ZST0yLWSZ0JFNgl02PM2yE46neMkqsCBRlSVlWt 6ze4jjPxncxoAgQpLDr54XgR1igZFRfrRFhCuWPAwYaoniJViwEJBIHxjFVeoNbVWKYu HPAQQ6/6WNNmi/y9wGldRljlBYp5f0TKAmPaCK8piOVDwVIyVJphzLJdJUOZPAOxRXjh CyQiu2HQIfu7xhViVZHPYaxecTvsszTZBePrEzf0LGDavOZw+e3FYx5tjCxg1CTP/pkp 6iQrwd+K5HreGnLMExHn37N5WfZWd4sF1t3sqF5XlCT9W9BNQgbG9n/x87HsuDqjIVnn Qgaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=orB03cCD+MWsUcnr98Ad8zioktb7E8jZuR1d0AKAVu4=; b=WoRxhNWWMKPUwOwoMAP6DtS448bniO7lnmYAzUWH1R5zciDYbCndwlnC0DfEexe69H vir2Yt2MD1xxPLONbC9msDjxCuwHcoycGY/DmTIQY+C6OeyRzYrNZ5eXgT3B9udfyNJ5 V87pxWd/nATsa7ZfekbpfbawzsWUR2iY1NV5YVbUjJtbE20Knyi28MMp4Gq6RvP3b7d3 M8XFXdpBF9/wRa9NeRGhkcKOEKvTIoNTBl+x2YfoodpcBLY3eZdQY93vOEYu4KIu11hw IKH1Jq9PZ2qg00h8vrK8ixZs71JQlFrPv6S/eUbJSgDtIRlvtS80WLHvkCUSd9RfVUjL 84RQ== 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v135-20020a63618d000000b003c5d888f2e5si847119pgb.364.2022.05.03.19.28.48; Tue, 03 May 2022 19:29:06 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244213AbiECXZY (ORCPT + 99 others); Tue, 3 May 2022 19:25:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244230AbiECXZW (ORCPT ); Tue, 3 May 2022 19:25:22 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95EF942ECD; Tue, 3 May 2022 16:21:44 -0700 (PDT) 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" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR,UPPERCASE_50_75 autolearn=no 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 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 > } >