From patchwork Wed Nov 30 23:41:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 13060821 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 DB927C4321E for ; Thu, 1 Dec 2022 00:11:59 +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:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DmXVEMSYIQpYfVPgw5q9xF6vaA/q0nVzd9AtJo/6zFU=; b=DYqZQ8vMv/8+Rl Hx5Lkd6jTCXzIECfNyyefTco+kZz13jxGqVHU2Ns80ovvNFfHuR24zh7vSnQXk/15kcjDHdZS6M5v 1ZL2nQDzmtOi2REu0q01IT1qnTK+KhRuiuVDMZ21RlNwhqel5+1+cNaNdUVQ+LDL3DhQVrDVM/ZGF plDlZI1Jx5NlvxnRiekG1DoSPy+EQryGbJjarEiXbuAzumfpozC5asjlqEaQB950TK3WjaQ7eH8FK 48UDYoUUDWu2fvc/1s2xZNaj4a74G0UOsi3wJNPI6nAjO0xKf04pfreL9FKyx6ZO+nCrM6DLdfsiu kW+E2Ob9DtX9v5YyZNOw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0XB9-003WzE-FN; Thu, 01 Dec 2022 00:11:51 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0WiH-003JmS-3W for linux-riscv@lists.infradead.org; Wed, 30 Nov 2022 23:42:02 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 2E70661E58; Wed, 30 Nov 2022 23:42:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF770C43140; Wed, 30 Nov 2022 23:41:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669851719; bh=pFJPFr1bYR15HN/6Ql3O3Nqt1/yhoHZv7oRl5CFhYeg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BfN7AZujL3v4Pw7dJ191/MllgmRUWFI98V/rTAYbF3N3CbKhzBPc25dHL5sTJYdMw w2JWddwtc/WP32pzOSYOmX3NV4bz4Cr+0bglMeVKBJa93VxHHHvqYk4rCtYGDWGpbR UvMzijLaqrKCYQkFw889UBx2mgpEp47UixWb34+2J5axA4ua6hBirhQh4HQ6qASDjz j62GI9CVGXcUI6xJtjy5Pjbs12QjnAZF5NLgtoKLNpef2ixQ1PRVovvGBRFWRQJEEU Cmk/1eAeufueb8lVEX72VFfRPApG0msXg1CFc+gfipCCUvhwNYib4YWqADLkCJ27g7 Lc/za5OEOtYDg== From: Conor Dooley To: Palmer Dabbelt , linux-riscv@lists.infradead.org Cc: Conor Dooley , ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org, corbet@lwn.net, guoren@kernel.org, heiko@sntech.de, paul.walmsley@sifive.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH v1 1/3] RISC-V: clarify ISA string ordering rules in cpu.c Date: Wed, 30 Nov 2022 23:41:24 +0000 Message-Id: <20221130234125.2722364-2-conor@kernel.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221130234125.2722364-1-conor@kernel.org> References: <20221130234125.2722364-1-conor@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221130_154201_300050_391ADF8C X-CRM114-Status: GOOD ( 18.17 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org From: Conor Dooley While the current list of rules may have been accurate when created it now lacks some clarity in the face of isa-manual updates. Instead of trying to continuously align this rule-set with the one in the specifications, change the role of this comment. This particular comment is important, as the array it "decorates" defines the order in which the ISA string appears to userspace in /proc/cpuinfo. Re-jig and strengthen the wording to provide contributors with a set order in which to add entries & note why this particular struct needs more attention than others. While in the area, add some whitespace and tweak some wording for readability's sake. Suggested-by: Andrew Jones Signed-off-by: Conor Dooley Reviewed-by: Andrew Jones --- arch/riscv/kernel/cpu.c | 49 ++++++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 13 deletions(-) diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index 852ecccd8920..68b2bd0cc3bc 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -120,22 +120,45 @@ device_initcall(riscv_cpuinfo_init); .uprop = #UPROP, \ .isa_ext_id = EXTID, \ } + /* - * Here are the ordering rules of extension naming defined by RISC-V - * specification : - * 1. All extensions should be separated from other multi-letter extensions - * by an underscore. - * 2. The first letter following the 'Z' conventionally indicates the most + * 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 multi-letter + * 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 should be ordered first - * by category, then alphabetically within a category. - * 3. Standard supervisor-level extensions (starts with 'S') should be - * listed after standard unprivileged extensions. If multiple - * supervisor-level extensions are listed, they should be ordered + * If multiple 'Z' extensions are named, they should 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. Non-standard extensions (starts with 'X') must be listed after all - * standard extensions. They must be separated from other multi-letter - * extensions by an underscore. + * + * 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 (starts with 'X') must be listed after all + * standard extensions. + * + * 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(sscofpmf, RISCV_ISA_EXT_SSCOFPMF), From patchwork Wed Nov 30 23:41:25 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 13060822 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 17090C4321E for ; Thu, 1 Dec 2022 00:12:08 +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:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Q9zCVTlIgYjD+FHCgmC/B/oS97KApbuwQqxRURtHFGU=; b=EaZ7YdX9J2ddQH 7WPijX1BV6cfeO2njG2H1wVjQdPctKGekyPeuMw5TtmXs3/KDoKcd4sitW6nBAEtlwrRxb5okgFdf cCXxa7r7sfOJnmqbb+xLZuYYLE7pn4tud9HGjoFO3dPiKtd7o2nkCKOOwTqmiHfip4Mqhb5kTddq7 Kc3SmadfObUkVbs8vRWRRkgKUU7khG4/R3PKhnWgZvuebCGqDk2EL3iNTbCL6AVNcJ5QllK2dj8Se yk8O6FVPZYZOBWLI9z6ilgidgHcMkzKYRuzBB0zK33hA6hx0pyEtOMhp3O+G8vm24FREXhmlbLsuV v5PG5M8QOOb8KzTf8vAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0XBI-003X34-3C; Thu, 01 Dec 2022 00:12:00 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0WiL-003JoC-7G for linux-riscv@lists.infradead.org; Wed, 30 Nov 2022 23:42:07 +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 84A88B81D59; Wed, 30 Nov 2022 23:42:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4780C43146; Wed, 30 Nov 2022 23:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669851722; bh=B0la+6RJs6jm7uimz2FZajJBMnUH9FoBQuI76+kXtl4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YtBDJB10K9UQhIScS5VPIjV21O/fMZFvs8VBNbVsqhX03H25iyKCeM7s3i+NZFjAU bmbBBqWZ0zzQ+v9UA7nXQIbkOkrj+2CijSK8khQ4qHE1WnXwOxLFI2pASuSSr9mMHc 2QRNvyEyJBEr+uOzLcB+JEJ+hsTHyv4uJmhOQdI3B7vyY3v1aZARRIMs98/CL1bGaq Qd4NKWdsQid2GnrZM6wI1uqUqlw2b97ljZHi/IrpCaj/Ikd1ItLa/YdR8TjcTu8Qh7 Ev128+zppZt3D/f8xCzCJ5gvumY6KavECn1g5T9kuh4fCxR/m9lEf6dvxJ4+dRsQK6 eezkFeuVMyLHQ== From: Conor Dooley To: Palmer Dabbelt , linux-riscv@lists.infradead.org Cc: Conor Dooley , ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org, corbet@lwn.net, guoren@kernel.org, heiko@sntech.de, paul.walmsley@sifive.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH v1 2/3] RISC-V: resort all extensions in consistent orders Date: Wed, 30 Nov 2022 23:41:25 +0000 Message-Id: <20221130234125.2722364-3-conor@kernel.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221130234125.2722364-1-conor@kernel.org> References: <20221130234125.2722364-1-conor@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221130_154205_609349_5A3CFE69 X-CRM114-Status: GOOD ( 16.00 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org From: Conor Dooley Ordering between each and every list of extensions is wildly inconsistent. Per discussion on the lists pick the following policy: - The array defining order in /proc/cpuinfo follows a narrow interpretation of the ISA specifications, described in a comment immediately presiding it. - All other lists of extensions are sorted alphabetically. This will hopefully allow for easier review & future additions, and reduce conflicts between patchsets as the number of extensions grows. Link: https://lore.kernel.org/all/20221129144742.2935581-2-conor.dooley@microchip.com/ Suggested-by: Andrew Jones Signed-off-by: Conor Dooley Reviewed-by: Andrew Jones Reviewed-by: Heiko Stuebner --- I could not decide between adding an alphabetical comment to each alphabetical site or not. I did it anyway. Scream if you hate it! I also moved a static branch thingy in this version, but that should not matter, right? riightt? --- arch/riscv/include/asm/hwcap.h | 12 +++++++----- arch/riscv/kernel/cpu.c | 4 ++-- arch/riscv/kernel/cpufeature.c | 6 ++++-- 3 files changed, 13 insertions(+), 9 deletions(-) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index b22525290073..ce522aad641a 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -51,14 +51,15 @@ extern unsigned long elf_hwcap; * RISCV_ISA_EXT_MAX. 0-25 range is reserved for single letter * extensions while all the multi-letter extensions should define the next * available logical extension id. + * Entries are sorted alphabetically. */ enum riscv_isa_ext_id { RISCV_ISA_EXT_SSCOFPMF = RISCV_ISA_EXT_BASE, + RISCV_ISA_EXT_SSTC, + RISCV_ISA_EXT_SVINVAL, RISCV_ISA_EXT_SVPBMT, RISCV_ISA_EXT_ZICBOM, RISCV_ISA_EXT_ZIHINTPAUSE, - RISCV_ISA_EXT_SSTC, - RISCV_ISA_EXT_SVINVAL, RISCV_ISA_EXT_ID_MAX = RISCV_ISA_EXT_MAX, }; @@ -66,11 +67,12 @@ enum riscv_isa_ext_id { * This enum represents the logical ID for each RISC-V ISA extension static * keys. We can use static key to optimize code path if some ISA extensions * are available. + * Entries are sorted alphabetically. */ enum riscv_isa_ext_key { RISCV_ISA_EXT_KEY_FPU, /* For 'F' and 'D' */ - RISCV_ISA_EXT_KEY_ZIHINTPAUSE, RISCV_ISA_EXT_KEY_SVINVAL, + RISCV_ISA_EXT_KEY_ZIHINTPAUSE, RISCV_ISA_EXT_KEY_MAX, }; @@ -90,10 +92,10 @@ static __always_inline int riscv_isa_ext2key(int num) return RISCV_ISA_EXT_KEY_FPU; case RISCV_ISA_EXT_d: return RISCV_ISA_EXT_KEY_FPU; - case RISCV_ISA_EXT_ZIHINTPAUSE: - return RISCV_ISA_EXT_KEY_ZIHINTPAUSE; case RISCV_ISA_EXT_SVINVAL: return RISCV_ISA_EXT_KEY_SVINVAL; + case RISCV_ISA_EXT_ZIHINTPAUSE: + return RISCV_ISA_EXT_KEY_ZIHINTPAUSE; default: return -EINVAL; } diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index 68b2bd0cc3bc..686d41b14206 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -161,12 +161,12 @@ device_initcall(riscv_cpuinfo_init); * 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(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), __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(svpbmt, RISCV_ISA_EXT_SVPBMT), - __RISCV_ISA_EXT_DATA(zicbom, RISCV_ISA_EXT_ZICBOM), - __RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE), __RISCV_ISA_EXT_DATA("", RISCV_ISA_EXT_MAX), }; diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 694267d1fe81..8a76a6ce70cf 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -199,12 +199,13 @@ void __init riscv_fill_hwcap(void) this_hwcap |= isa2hwcap[(unsigned char)(*ext)]; set_bit(*ext - 'a', this_isa); } else { + /* sorted alphabetically */ SET_ISA_EXT_MAP("sscofpmf", RISCV_ISA_EXT_SSCOFPMF); + SET_ISA_EXT_MAP("sstc", RISCV_ISA_EXT_SSTC); + SET_ISA_EXT_MAP("svinval", RISCV_ISA_EXT_SVINVAL); SET_ISA_EXT_MAP("svpbmt", RISCV_ISA_EXT_SVPBMT); SET_ISA_EXT_MAP("zicbom", RISCV_ISA_EXT_ZICBOM); SET_ISA_EXT_MAP("zihintpause", RISCV_ISA_EXT_ZIHINTPAUSE); - SET_ISA_EXT_MAP("sstc", RISCV_ISA_EXT_SSTC); - SET_ISA_EXT_MAP("svinval", RISCV_ISA_EXT_SVINVAL); } #undef SET_ISA_EXT_MAP } @@ -284,6 +285,7 @@ static bool __init_or_module cpufeature_probe_zicbom(unsigned int stage) * This code may also be executed before kernel relocation, so we cannot use * addresses generated by the address-of operator as they won't be valid in * this context. + * Tests, unless otherwise required, are to be added in alphabetical order. */ static u32 __init_or_module cpufeature_probe(unsigned int stage) { From patchwork Wed Nov 30 23:41:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 13060823 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 37814C47089 for ; Thu, 1 Dec 2022 00:12:12 +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:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uPlJmaS2QG2scUoJEu3IbT2iN+t6kuvwIgIFcPIXD8E=; b=wjwvJy/CvlGC9A GfKBECAQNdY3vJxMPOn7WG283RvBbK0nFqoV1mcwwiaN/eL5qmmjVUYLuHIgP6m6+fMgAso2AjDGF up1WfRkRDFUJ5Oq5xuodT26j6uX8aHxRKt/8cL3LH0flhJHntw9Tyw2P26MIHysqZw8bDv0e/RYAE cA+DxGmLwsfl7Y3WlbC/j4C8BEeEM5jPQ9OeuxEpt0Tkl01HV4n3KaizsQ1az5hdzd3ia+V7l3OvF ojsaQTEy3ote/nrgHaX+NUqOCc84SVZbZkhRAvn7mbzZbbCHUmz0QLivXwVst3XaC7HrAAazxE8l0 LA4P3drfnrROIbWakjhg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0XBM-003X5v-6d; Thu, 01 Dec 2022 00:12:04 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0WiN-003Jpr-OL for linux-riscv@lists.infradead.org; Wed, 30 Nov 2022 23:42:09 +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 63BABB81D76; Wed, 30 Nov 2022 23:42:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B89BFC4347C; Wed, 30 Nov 2022 23:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669851725; bh=Z7aEnVV+jWqoN52K1e+YmgnpAmHL+qz1PmK3NhAzRxQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EnIw4/IrxANCSz/9VMiRA2KIF6h3JhMAHa/K90/tVJu+PWuZwyGcVwk6Y/zm+B+jL SlBUCNPTLbcVhrHzZob+j5KwC/UXl07hBKXLBafS0wmQjHhK9Fw9J/vp4+JR7Y94uS TBP2keeu8Tg48fv4xCCzWzvNHS7gGuGlALoUG+FhDzeU/snOwUnk+ZLnOvmNTK/YGA lnuxunckxgcjRYxr0IB9pBW+hzIHmoPtb27IEAy2PWT44dlttLMlsVwte40Y/vhbPA sVQJHXRlDzCKMWkh3ALONUhRQT9ISq2l2EOKGhVynuXRuW2SWJGFVPd6riRsdahpDe SiRZLV22KB8Hw== From: Conor Dooley To: Palmer Dabbelt , linux-riscv@lists.infradead.org Cc: Conor Dooley , ajones@ventanamicro.com, aou@eecs.berkeley.edu, conor@kernel.org, corbet@lwn.net, guoren@kernel.org, heiko@sntech.de, paul.walmsley@sifive.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH v1 3/3] Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo Date: Wed, 30 Nov 2022 23:41:26 +0000 Message-Id: <20221130234125.2722364-4-conor@kernel.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221130234125.2722364-1-conor@kernel.org> References: <20221130234125.2722364-1-conor@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221130_154208_137999_4F32A1E0 X-CRM114-Status: GOOD ( 12.75 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org From: Conor Dooley The RISC-V specs are permissive in what they allow as the ISA string, but how we output this to userspace in /proc/cpuinfo is quasi uAPI. Formalise this as part of the uAPI, by documenting the list of rules we use at this point in time. Signed-off-by: Conor Dooley --- I've not "tested" these docs. The NIPA-esque pwbot should go and test it AFAICT. If it doesn't, I'll go add that. --- Documentation/riscv/uabi.rst | 42 ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/Documentation/riscv/uabi.rst b/Documentation/riscv/uabi.rst index 21a82cfb6c4d..bc3c8ced644b 100644 --- a/Documentation/riscv/uabi.rst +++ b/Documentation/riscv/uabi.rst @@ -3,4 +3,46 @@ RISC-V Linux User ABI ===================== +Misaligned accesses +------------------- + Misaligned accesses are supported in userspace, but they may perform poorly. + +ISA string ordering in /proc/cpuinfo +------------------------------------ + +The canonical order of ISA extension names in the ISA string is defined in +chapter 27 of the unprivileged specification. +The specification uses vague wording, such as should, when it comes to +ordering, so for our purposes the following rules apply: + +#. Single-letter extensions come first, in "canonical order", so + "IMAFDQLCBKJTPVH". + +#. All multi-letter extensions will be separated from other multi-letter + extensions by an underscore. + +#. Additional standard extensions (starting with 'Z') will be sorted after + single-letter extensions and before any higher-privileged extensions. + +#. The first letter following the 'Z' conventionally indicates the most + closely related alphabetical extension category, IMAFDQLCBKJTPVH. + If multiple 'Z' extensions are named, they should be ordered first by + category, then alphabetically within a category. + +#. Standard supervisor-level extensions (starting with 'S') will be listed + after standard unprivileged extensions. If multiple + supervisor-level extensions are listed, they will be ordered + alphabetically. + +#. Standard machine-level extensions (starting with 'Zxm') will be listed + after any lower-privileged, standard extensions. If multiple + machine-level extensions are listed, they will be ordered + alphabetically. + +#. Non-standard extensions (starts with 'X') will be listed after all + standard extensions. + +An example string following the order is: + rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux +