Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3155566rwb; Wed, 30 Nov 2022 16:25:01 -0800 (PST) X-Google-Smtp-Source: AA0mqf7jgJx/56wyfjTR0ywClfuDaMOJLJS0dlrJzPwg6LASZzKEVp9caY7oJVQ2sU57cVREnyJC X-Received: by 2002:a17:906:583:b0:78d:9e18:b8f7 with SMTP id 3-20020a170906058300b0078d9e18b8f7mr52074891ejn.657.1669854301732; Wed, 30 Nov 2022 16:25:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669854301; cv=none; d=google.com; s=arc-20160816; b=Ae4MLnD0ZzISlbYvA/KCqW5MEb8wZvzQ+KtqIQb3wR2vrrRS9+/6cGjXLEtpmnyVTt 30ZfnfyFLEzutHRfHbTLgi+4/PaI9YfWBwd5XpDiHwolwGIQ6lZYUB69qK1rOpu33a36 DHsu6OpeWJ90N0ZvRDdWzIdB58hciRjaM21sHcGrOqIWu6Bw7A0ehKc1fzuctrMD5R1z GIkPc12+LSrm30MXt1g6iL/z3CoyKwnx4kuReaEaBpjA3YAiYREw+MMcSWxeN5JtONMh BhqtrtW8wxIBsaoEjWoWv9TqxIDP+pnFZXTRt9BzawWviz8Nr3ceAvHAYYwSCDpBb0sA Dl6g== 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=v0nT565fuLxS7Sjmg1cz0D0+ch0oiIoBSEULtxN/oLI=; b=qwUAtItnvg2/8x2+agACROYkCURxhTRWmaha0mD3byRcRMoPWt0y9OjskeJkkcDV7s mCKva82egS2QA1JafrEMPTyXZZ/KGMeb2KrH0JTm+8jAGSMw/eLQTS+VJaBP0Pkc+2T/ FO7Q1JfmlRACNW63R33kwj/2KsqgPi8qIw627klyLXu2VzbfmfyOItdiZ12ICfB9dCSr Jffok7qy0wDIdXMJWs/qS9MOAcrxGArsZ4cLC4j1FC5eVNdj6vsJuXnNl0iUfzO8qE4j RYZCp0kQJMItKtpR3sPFjp0zzdmQlTQVBwNDdwGeZd/4ezNZIvwWv8qpMDmw+puqsAmA xcFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BfN7AZuj; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z18-20020a056402275200b0046649cd87c2si2372226edd.32.2022.11.30.16.24.41; Wed, 30 Nov 2022 16:25:01 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=BfN7AZuj; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229914AbiK3XmH (ORCPT + 84 others); Wed, 30 Nov 2022 18:42:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbiK3XmC (ORCPT ); Wed, 30 Nov 2022 18:42:02 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E99884D5FA; Wed, 30 Nov 2022 15:42:01 -0800 (PST) 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 AE9EFB81D59; 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 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 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 --- 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), -- 2.38.1