From patchwork Mon Jul 3 10:27:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 115304 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp426389vqx; Mon, 3 Jul 2023 03:45:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5tw/MoCl8qsnnNf3g1jw2KkGmcuRE1YPQq1bQZ/w12n0/CUP3BoqNv53ZnospmQsakhN5n X-Received: by 2002:a05:6a21:999a:b0:11a:dbb3:703b with SMTP id ve26-20020a056a21999a00b0011adbb3703bmr15749087pzb.6.1688381157685; Mon, 03 Jul 2023 03:45:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688381157; cv=none; d=google.com; s=arc-20160816; b=U9J7sIzxVTnMPq0qGrTEKE/WDwEJ5INUFxNoPltOhRanUUeTYK2ElQD0j1mCqf5fo5 kWd+OH5uTfuim/RGmunyo9D/U4FJZ1h7+cjNdLcG5KrekbjG9hhINm7DwNhr8QIS6PaG v4Ygc7gDzKBpOYSzL4QzEn15x2qRBnqai+fYdhYYH/oekLnypUWg+cPib0rP7F+gi7UM LowaEa1tTFWeTYigpWzi/6xMZYvusMQ6m1Kh6dgOGYv9eVmUczqDxOWMQNqntxt5avEh IxNawbgPRlhgEUdB7gepc7+6D+vYDGTVbHpApYZhtmw5ZlPuUJ8vaYeqCZbHT6jJKzzh aKqA== 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 :dkim-signature; bh=Z7u2v8kBbunTsPTb/9JmrgRrWiuo3QvCrawfiqXbRQg=; fh=bxJz0t5bp5GEu+Lq5f6BwBZjyRyJDg2/TVrU9Vjahow=; b=MSUlIhs+gasiMnt6KoGFK4Ty75QXxL4WFhJCq0FHJO0WvGegmwk4In92sIq36wVI3S KU9d6nBOnDCLKbxKC6i+TVQBZq2GmyJ9zt6M3VZOHQPDL6YMjPmtOBuyci+eG6wz/1lO 5tSijy+I8Sw+LulchURsR87RGZMj50xOIunikq7hhBe99BOiCYjfwmVmpahA3cRiwRhc eZMtWnedzH61EhcLXr7Vm6lInAP1BhDY6VgPreSIJ03RMO3zuVcoscXcZ3gTPbt5p2LR lu8eC0589fr8SdCBay8CbRPDihhO8JxZyT6eDVvvWv51bCqCn1rfrAMyP6NzOVUoaq+N rwtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b=GOgVcZhx; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fa2-20020a056a002d0200b006825b83dca7si8115755pfb.301.2023.07.03.03.45.42; Mon, 03 Jul 2023 03:45:57 -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; dkim=pass header.i=@microchip.com header.s=mchp header.b=GOgVcZhx; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231416AbjGCK33 (ORCPT + 99 others); Mon, 3 Jul 2023 06:29:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231344AbjGCK3Q (ORCPT ); Mon, 3 Jul 2023 06:29:16 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72DF5DF; Mon, 3 Jul 2023 03:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1688380153; x=1719916153; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nFZWFc6aPVJ+htn5+aiEpwZPvD0IFr2qwbQIZVrw0Og=; b=GOgVcZhxoqruJ9Msq8sflCDmt+SAEoY6a+dDcGwDdIt9P6PbXhsnsNIT QqkPe8otmyP86bs9/B3ZPZGxEbae7yE47fY/2U5VZBtAOiHhPE0BO1f99 3XCgdIz/ugwUg9KwGrTwlWoyyba9RDYbgn+DIyV4278y6CyZgTs921y0q JkX6Mxj2IeJ/ko9FXFSlgDx1+jjHVD8qZgTLE1xmCl9ZzL/hdhyIjf1wK mtOYyMpa+IWfBRx7SAk8Tj89bdFTybU+502wJ2bs+IE3fpizVN4hjqu12 TARTJhBIXnuwj6zUjIYgEYT4/Y2leKlvOJ4mcO3LUimWMMc0hkuJw7/+8 w==; X-IronPort-AV: E=Sophos;i="6.01,177,1684825200"; d="scan'208";a="233446753" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 03 Jul 2023 03:29:11 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 3 Jul 2023 03:29:09 -0700 Received: from wendy.microchip.com (10.10.115.15) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.2507.21 via Frontend Transport; Mon, 3 Jul 2023 03:29:06 -0700 From: Conor Dooley To: CC: , , Rob Herring , Krzysztof Kozlowski , Paul Walmsley , Albert Ou , "Jonathan Corbet" , Andrew Jones , "Heiko Stuebner" , Evan Green , Sunil V L , , , , Subject: [PATCH v3 04/11] RISC-V: shunt isa_ext_arr to cpufeature.c Date: Mon, 3 Jul 2023 11:27:56 +0100 Message-ID: <20230703-steadying-skintight-d5b7c108551c@wendy> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230703-repayment-vocalist-e4f3eeac2b2a@wendy> References: <20230703-repayment-vocalist-e4f3eeac2b2a@wendy> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=8733; i=conor.dooley@microchip.com; h=from:subject:message-id; bh=nFZWFc6aPVJ+htn5+aiEpwZPvD0IFr2qwbQIZVrw0Og=; b=owGbwMvMwCFWscWwfUFT0iXG02pJDCmLFq1KX3yS+3vI10Lmf+IlmxmmdH/8cCfQ9eWh9hxfuUWC 0i3+HaUsDGIcDLJiiiyJt/tapNb/cdnh3PMWZg4rE8gQBi5OAZhI/gRGhs2s848G8+S4WD7Y0rVoD/ OvSOfyCXMZnNy6m9ua2Y1XnGX4p3xZPDr91cyPT/Tj13m129ox+q/YwRyeuu7ZXX39LZMl+AE= X-Developer-Key: i=conor.dooley@microchip.com; a=openpgp; fpr=F9ECA03CF54F12CD01F1655722E2C55B37CF380C X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770395960984015578?= X-GMAIL-MSGID: =?utf-8?q?1770395960984015578?= To facilitate using one struct to define extensions, rather than having several, shunt isa_ext_arr to cpufeature.c, where it will be used for probing extension presence also. As that scope of the array as widened, prefix it with riscv & drop the type from the variable name. Since the new array is const, print_isa() needs a wee bit of cleanup to avoid complaints about losing the const qualifier. Reviewed-by: Andrew Jones Signed-off-by: Conor Dooley Reviewed-by: Evan Green --- Changes in v2: - Drop the empty element from the end of the array, it was adding a bug anyway as I was not decrementing the result of ARRAY_SIZE() by one. Likely I meant to drop it originally and forgot, as dropping the decrement was intentional. --- arch/riscv/include/asm/hwcap.h | 3 ++ arch/riscv/kernel/cpu.c | 75 +--------------------------------- arch/riscv/kernel/cpufeature.c | 67 ++++++++++++++++++++++++++++++ 3 files changed, 72 insertions(+), 73 deletions(-) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index f041bfa7f6a0..7a57e6109aef 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -76,6 +76,9 @@ struct riscv_isa_ext_data { unsigned int isa_ext_id; }; +extern const struct riscv_isa_ext_data riscv_isa_ext[]; +extern const size_t riscv_isa_ext_count; + unsigned long riscv_isa_extension_base(const unsigned long *isa_bitmap); #define riscv_isa_extension_mask(ext) BIT_MASK(RISCV_ISA_EXT_##ext) diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index e721f15fdf17..bf93293d51f3 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -164,81 +164,10 @@ arch_initcall(riscv_cpuinfo_init); #ifdef CONFIG_PROC_FS -#define __RISCV_ISA_EXT_DATA(UPROP, EXTID) \ - { \ - .uprop = #UPROP, \ - .isa_ext_id = EXTID, \ - } - -/* - * The canonical order of ISA extension names in the ISA string is defined in - * chapter 27 of the unprivileged specification. - * - * Ordinarily, for in-kernel data structures, this order is unimportant but - * isa_ext_arr defines the order of the ISA string in /proc/cpuinfo. - * - * The specification uses vague wording, such as should, when it comes to - * ordering, so for our purposes the following rules apply: - * - * 1. All multi-letter extensions must be separated from other extensions by an - * underscore. - * - * 2. Additional standard extensions (starting with 'Z') must be sorted after - * single-letter extensions and before any higher-privileged extensions. - - * 3. The first letter following the 'Z' conventionally indicates the most - * closely related alphabetical extension category, IMAFDQLCBKJTPVH. - * If multiple 'Z' extensions are named, they must be ordered first by - * category, then alphabetically within a category. - * - * 3. Standard supervisor-level extensions (starting with 'S') must be listed - * after standard unprivileged extensions. If multiple supervisor-level - * extensions are listed, they must be ordered alphabetically. - * - * 4. Standard machine-level extensions (starting with 'Zxm') must be listed - * after any lower-privileged, standard extensions. If multiple - * machine-level extensions are listed, they must be ordered - * alphabetically. - * - * 5. Non-standard extensions (starting with 'X') must be listed after all - * standard extensions. If multiple non-standard extensions are listed, they - * must be ordered alphabetically. - * - * An example string following the order is: - * rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux - * - * New entries to this struct should follow the ordering rules described above. - */ -static struct riscv_isa_ext_data isa_ext_arr[] = { - __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), - __RISCV_ISA_EXT_DATA(zicboz, RISCV_ISA_EXT_ZICBOZ), - __RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR), - __RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR), - __RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI), - __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), - __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), - __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), - __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), - __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), - __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), - __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), - __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), - __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), - __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), - __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT), - __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), - __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), -}; - static void print_isa_ext(struct seq_file *f) { - struct riscv_isa_ext_data *edata; - int i = 0, arr_sz; - - arr_sz = ARRAY_SIZE(isa_ext_arr) - 1; - - for (i = 0; i <= arr_sz; i++) { - edata = &isa_ext_arr[i]; + for (int i = 0; i < riscv_isa_ext_count; i++) { + const struct riscv_isa_ext_data *edata = &riscv_isa_ext[i]; if (!__riscv_isa_extension_available(NULL, edata->isa_ext_id)) continue; seq_printf(f, "_%s", edata->uprop); diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index bdcf460ea53d..fb476153fffc 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -99,6 +99,73 @@ static bool riscv_isa_extension_check(int id) return true; } +#define __RISCV_ISA_EXT_DATA(UPROP, EXTID) \ + { \ + .uprop = #UPROP, \ + .isa_ext_id = EXTID, \ + } + +/* + * The canonical order of ISA extension names in the ISA string is defined in + * chapter 27 of the unprivileged specification. + * + * Ordinarily, for in-kernel data structures, this order is unimportant but + * isa_ext_arr defines the order of the ISA string in /proc/cpuinfo. + * + * The specification uses vague wording, such as should, when it comes to + * ordering, so for our purposes the following rules apply: + * + * 1. All multi-letter extensions must be separated from other extensions by an + * underscore. + * + * 2. Additional standard extensions (starting with 'Z') must be sorted after + * single-letter extensions and before any higher-privileged extensions. + * + * 3. The first letter following the 'Z' conventionally indicates the most + * closely related alphabetical extension category, IMAFDQLCBKJTPVH. + * If multiple 'Z' extensions are named, they must be ordered first by + * category, then alphabetically within a category. + * + * 3. Standard supervisor-level extensions (starting with 'S') must be listed + * after standard unprivileged extensions. If multiple supervisor-level + * extensions are listed, they must be ordered alphabetically. + * + * 4. Standard machine-level extensions (starting with 'Zxm') must be listed + * after any lower-privileged, standard extensions. If multiple + * machine-level extensions are listed, they must be ordered + * alphabetically. + * + * 5. Non-standard extensions (starting with 'X') must be listed after all + * standard extensions. If multiple non-standard extensions are listed, they + * must be ordered alphabetically. + * + * An example string following the order is: + * rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux + * + * New entries to this struct should follow the ordering rules described above. + */ +const struct riscv_isa_ext_data riscv_isa_ext[] = { + __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), + __RISCV_ISA_EXT_DATA(zicboz, RISCV_ISA_EXT_ZICBOZ), + __RISCV_ISA_EXT_DATA(zicntr, RISCV_ISA_EXT_ZICNTR), + __RISCV_ISA_EXT_DATA(zicsr, RISCV_ISA_EXT_ZICSR), + __RISCV_ISA_EXT_DATA(zifencei, RISCV_ISA_EXT_ZIFENCEI), + __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), + __RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM), + __RISCV_ISA_EXT_DATA(zba, RISCV_ISA_EXT_ZBA), + __RISCV_ISA_EXT_DATA(zbb, RISCV_ISA_EXT_ZBB), + __RISCV_ISA_EXT_DATA(zbs, RISCV_ISA_EXT_ZBS), + __RISCV_ISA_EXT_DATA(smaia, RISCV_ISA_EXT_SMAIA), + __RISCV_ISA_EXT_DATA(ssaia, RISCV_ISA_EXT_SSAIA), + __RISCV_ISA_EXT_DATA(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), + __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), + __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), + __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT), + __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT), +}; + +const size_t riscv_isa_ext_count = ARRAY_SIZE(riscv_isa_ext); + void __init riscv_fill_hwcap(void) { struct device_node *node;