From: sashiko-bot@kernel.org
To: "Yu-Chien Peter Lin" <peter.lin@sifive.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [RFC PATCH 1/3] dt-bindings: riscv: Add Worlds ISA extensions
Date: Fri, 19 Jun 2026 10:57:30 +0000 [thread overview]
Message-ID: <20260619105730.9CE121F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260619105834.1277302-2-peter.lin@sifive.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The descriptions for the newly added RISC-V Worlds ISA extensions use placeholder 'TBD' text instead of a valid specification commit hash.
- [Low] The newly added multi-letter ISA extensions `smlwid` and `smlwidlist` are not sorted alphanumerically.
--
commit 16fbfa5650f850f6481cd820aa9d7deb379f7452
Author: Yu-Chien Peter Lin <peter.lin@sifive.com>
dt-bindings: riscv: Add Worlds ISA extensions
This commit adds device tree bindings for the RISC-V Worlds ISA extensions.
These extensions are used to tag transactions with World IDs that hardware
uses to enforce isolation across execution contexts.
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 2b0a8a93bb214..1bc8b1aa67c06 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -193,12 +193,35 @@ properties:
> ratified at commit d70011dde6c2 ("Update to ratified state")
> of riscv-j-extension.
>
> + - const: smlwid
[Severity: Low]
This isn't a bug, but are these extensions placed in the correct alphabetical
order? Multi-letter extensions are typically required to be sorted
alphanumerically, and "smlwid" appears to be inserted out of order relative
to other "sm" extensions.
> + description: |
> + The standard Smlwid extension for M-mode control of lower
> + privilege World ID via the mlwid CSR as ratified at commit
> + TBD ("TBD") of riscv-worlds.
[Severity: Medium]
Is the "TBD" placeholder intended to be kept in the final binding? Device tree
bindings usually require a specific commit hash to reference a frozen or
ratified specification.
> +
> + - const: smlwidlist
> + description: |
> + The standard Smlwidlist extension for M-mode control of lower
> + privilege World IDs via the mlwidlist CSR as ratified at commit
> + TBD ("TBD") of riscv-worlds.
[Severity: Medium]
Does this also need to be updated with the actual ratification commit hash
instead of the placeholder?
> +
> - const: smstateen
> description: |
> The standard Smstateen extension for controlling access to CSRs
> added by other RISC-V extensions in H/S/VS/U/VU modes and as
> ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable.
>
> + - const: smwdeleg
> + description: |
> + The standard Smwdeleg extension for M-mode delegation of lower
> + privilege World ID control to S-mode via the mwiddeleg CSR, as
> + ratified at commit TBD ("TBD") of riscv-worlds.
[Severity: Medium]
Is the exact specification commit hash available to replace the placeholder
text here?
> +
> + - const: smwid
> + description: |
> + The standard Smwid extension for M-mode World ID control via the
> + mwid CSR as ratified at commit TBD ("TBD") of riscv-worlds.
[Severity: Medium]
Can we include the specific commit hash of riscv-worlds here instead of
using the temporary text?
[ ... ]
> @@ -262,6 +285,12 @@ properties:
> ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
> ("Updated to ratified state.")
>
> + - const: sswid
> + description: |
> + The standard Sswid extension for S-mode control of lower
> + privilege World IDs via the slwid CSR as ratified at commit
> + TBD ("TBD") of riscv-worlds.
[Severity: Medium]
Is the placeholder expected to be replaced with the actual ratification
commit before this is merged?
> +
> - const: supm
> description: |
> The standard Supm extension for pointer masking support in user
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619105834.1277302-1-peter.lin@sifive.com?part=1
next prev parent reply other threads:[~2026-06-19 10:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 10:58 [RFC PATCH 0/3] dt-bindings: riscv: Add RISC-V Worlds and SiFive WorldGuard DT bindings Yu-Chien Peter Lin
2026-06-19 10:58 ` [RFC PATCH 1/3] dt-bindings: riscv: Add Worlds ISA extensions Yu-Chien Peter Lin
2026-06-19 10:57 ` sashiko-bot [this message]
2026-06-19 10:58 ` [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties Yu-Chien Peter Lin
2026-06-19 10:59 ` sashiko-bot
2026-06-19 10:58 ` [RFC PATCH 3/3] dt-bindings: sifive: Add WorldGuard Checker Yu-Chien Peter Lin
2026-06-19 10:59 ` sashiko-bot
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=20260619105730.9CE121F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=peter.lin@sifive.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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