Devicetree
 help / color / mirror / Atom feed
From: Andrew Jones <ajones@ventanamicro.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: linux-riscv@lists.infradead.org, aou@eecs.berkeley.edu,
	conor@kernel.org, devicetree@vger.kernel.org, guoren@kernel.org,
	heiko@sntech.de, krzysztof.kozlowski+dt@linaro.org,
	linux-kernel@vger.kernel.org, palmer@dabbelt.com,
	paul.walmsley@sifive.com, robh+dt@kernel.org
Subject: Re: [RFC 1/2] RISC-V: clarify ISA string ordering rules in cpu.c
Date: Tue, 29 Nov 2022 17:12:23 +0100	[thread overview]
Message-ID: <20221129161223.gelsvctfnqg7pdwb@kamzik> (raw)
In-Reply-To: <20221129144742.2935581-2-conor.dooley@microchip.com>

On Tue, Nov 29, 2022 at 02:47:42PM +0000, Conor Dooley wrote:
> While the list of rules may have been accurate when created, it now
> lacks some clarity in the face of isa-manual updates. Specifically:
> 
> - there is no mention here of a distinction between regular 'Z'
>   extensions which are "Additional Standard Extensions" and "Zxm"
>   extensions which are "Standard Machine-Level Extensions"
> 
> - there is also no explicit mention of where either should be sorted in
>   the list
> 
> - underscores are only required between two *multi-letter* extensions but
>   the list of rules implies that this is required between a multi-letter
>   extension and any other extension. IOW "rv64imafdzicsr_zifencei" is a
>   valid string
> 
> Attempt to clean up the list of rules, by adding information on the
> above & sprinkling in some white space for readability.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  arch/riscv/kernel/cpu.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index 852ecccd8920..5e42c92a8456 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -120,20 +120,32 @@ 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.
> + *
> + * 1. All multi-letter extensions should be separated from other multi-letter
> + *    extensions by an underscore.
> + *
>   * 2. 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.
> + *    'Z' extensions should be sorted after single-letter extensions and before
> + *    any higher-privileged extensions.
> + *    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
>   *    alphabetically.
> - * 4. Non-standard extensions (starts with 'X') must be listed after all
> + *
> + * 4  Standard machine-level extensions (starts with 'Zxm') should be
> + *    listed after any lower-privileged, standard extensions.  If multiple
> + *    machine-level extensions are listed, they should be ordered
> + *    alphabetically.
> + *
> + * 5. 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.
>   */
> -- 
> 2.38.1
>

Alternatively, we could change the comment to just point out the spec
chapter and provide an example, e.g.

/*
 * The canonical order of ISA extension names in the ISA string is defined in
 * chapter 27 of the unprivileged spec. An example string following the
 * order is
 *
 *   rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
 *
 * Notice how Z-extensions are first sorted by category using the canonical
 * order of the first letter following the Z. Extension groups are in the
 * order specified in chapter 27. Extensions within each group are sorted
 * alphabetically.
 */


Thanks,
drew

  reply	other threads:[~2022-11-29 16:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24 13:04 [PATCH 0/2] riscv,isa fixups Conor Dooley
2022-11-24 13:04 ` [PATCH 1/2] dt-bindings: riscv: fix underscore requirement for addtional standard extensions Conor Dooley
2022-11-25  1:12   ` Guo Ren
2022-11-24 13:04 ` [PATCH 2/2] dt-bindings: riscv: fix single letter canonical order Conor Dooley
2022-11-24 13:42   ` Heiko Stübner
2022-11-24 13:52     ` Conor Dooley
2022-11-28 17:41     ` Palmer Dabbelt
2022-11-28 18:08       ` Conor Dooley
2022-11-28 18:12         ` Palmer Dabbelt
2022-11-28 19:17           ` Conor Dooley
2022-11-28 23:41             ` Palmer Dabbelt
2022-11-29  5:19               ` Andrew Jones
2022-11-29 11:40                 ` Conor Dooley
2022-11-29 14:47                   ` [RFC 0/2] Putting some basic order on isa extension stuff Conor Dooley
2022-11-29 15:48                     ` Andrew Jones
2022-11-29 16:50                       ` Conor Dooley
2022-11-29 14:47                   ` [RFC 1/2] RISC-V: clarify ISA string ordering rules in cpu.c Conor Dooley
2022-11-29 16:12                     ` Andrew Jones [this message]
2022-11-29 16:54                       ` Conor Dooley
2022-11-29 17:19                         ` Andrew Jones
2022-11-29 17:48                           ` Conor Dooley
2022-11-29 14:47                   ` [RFC 2/2] RISC-V: resort all extensions in "canonical" order Conor Dooley
2022-11-29 16:35                     ` Andrew Jones
2022-11-25  1:13   ` [PATCH 2/2] dt-bindings: riscv: fix single letter canonical order Guo Ren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221129161223.gelsvctfnqg7pdwb@kamzik \
    --to=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox