All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Atish Patra" <atish.patra@linux.dev>
Cc: conor+dt@kernel.org, linux-perf-users@vger.kernel.org,
	robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 09/21] dt-bindings: riscv: add Counter delegation ISA extensions description
Date: Tue, 09 Jun 2026 06:12:38 +0000	[thread overview]
Message-ID: <20260609061239.160901F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260608-counter_delegation-v6-9-285b72ed65a9@meta.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Incorrect dependency for smcdeleg: depends on sscsrind instead of smcsrind.
- [Medium] The ssccfg extension is over-constrained by strictly requiring smcntrpmf.
- [Low] Contradictory description for the smcdeleg extension.
--

commit 53fb261803de68f9caaa685d63588c9cac6c0f5c
Author: Atish Patra <atishp@rivosinc.com>

dt-bindings: riscv: add Counter delegation ISA extensions description

This commit adds device tree binding descriptions for the Smcdeleg and
Ssccfg RISC-V ISA extensions. It also specifies the conditional dependencies
required for these extensions to pass schema validation.

> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index ece3edccee42c..2845e8e2999a7 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -181,6 +181,13 @@ properties:
>              changes to interrupts as frozen at commit ccbddab ("Merge pull
>              request #42 from riscv/jhauser-2023-RC4") of riscv-aia.
>  
> +        - const: smcdeleg
> +          description: |
> +            The standard Smcdeleg supervisor-level extension for the machine mode

[Severity: Low]
This isn't a bug, but should this say machine-level instead of
supervisor-level? Since it has an Sm prefix and is meant for machine mode,
calling it a supervisor-level extension might be a copy-paste typo.

> +            to delegate the hpmcounters to supervisor mode so that they are
> +            directly accessible in the supervisor mode as ratified in the
> +            20240213 version of the privileged ISA specification.

[ ... ]

> @@ -1135,6 +1150,36 @@ properties:
>              allOf:
>                - const: zilsd
>                - const: zca
> +      # Smcdeleg depends on Sscsrind, Zihpm, Zicntr
> +      - if:
> +          contains:
> +            const: smcdeleg
> +        then:
> +          allOf:
> +            - contains:
> +                const: sscsrind

[Severity: Medium]
Does smcdeleg actually depend on sscsrind here?

Since smcdeleg is a machine-mode extension that uses M-mode indirect CSRs to
delegate counters, shouldn't it depend on the smcsrind extension instead of
sscsrind? If a valid hardware configuration implements smcsrind and smcdeleg
without sscsrind, would this schema incorrectly reject it?

> +            - contains:
> +                const: zihpm
> +            - contains:
> +                const: zicntr
> +      # Ssccfg depends on Smcdeleg, Sscsrind, Zihpm, Zicntr, Sscofpmf, Smcntrpmf
> +      - if:
> +          contains:
> +            const: ssccfg
> +        then:
> +          allOf:
> +            - contains:
> +                const: smcdeleg
> +            - contains:
> +                const: sscsrind
> +            - contains:
> +                const: sscofpmf
> +            - contains:
> +                const: smcntrpmf

[Severity: Medium]
Is smcntrpmf a strict requirement for ssccfg?

The ssccfg extension provides supervisor-mode access to delegated counters,
but the kernel implementation seems to only conditionally expose
cyclecfg/instretcfg CSRs if smcntrpmf is present. If ssccfg can exist
independently, will requiring smcntrpmf in this binding incorrectly fail
validation for valid hardware that omits it?

> +            - contains:
> +                const: zihpm
> +            - contains:
> +                const: zicntr

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-counter_delegation-v6-0-285b72ed65a9@meta.com?part=9

  reply	other threads:[~2026-06-09  6:12 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09  6:01 [PATCH v6 00/21] Add Counter delegation ISA extension support Atish Patra
2026-06-09  6:01 ` Atish Patra
2026-06-09  6:01 ` [PATCH v6 01/21] RISC-V: Add Sxcsrind ISA extension CSR definitions Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:01 ` [PATCH v6 02/21] RISC-V: Add Sxcsrind ISA extension definition and parsing Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:01 ` [PATCH v6 03/21] dt-bindings: riscv: add Sxcsrind ISA extension description Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:09   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 04/21] RISC-V: Define indirect CSR access helpers Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:15   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 05/21] RISC-V: Add Smcntrpmf extension parsing Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:01 ` [PATCH v6 06/21] dt-bindings: riscv: add Smcntrpmf ISA extension description Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:09   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 07/21] RISC-V: Add Sscfg extension CSR definition Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:01 ` [PATCH v6 08/21] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:14   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 09/21] dt-bindings: riscv: add Counter delegation ISA extensions description Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:12   ` sashiko-bot [this message]
2026-06-09  6:01 ` [PATCH v6 10/21] RISC-V: perf: Restructure the SBI PMU code Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:18   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 11/21] RISC-V: perf: Modify the counter discovery mechanism Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:17   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 12/21] RISC-V: perf: Add a mechanism to defined legacy event encoding Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:16   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 13/21] RISC-V: perf: Implement supervisor counter delegation support Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:23   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 14/21] RISC-V: perf: Skip PMU SBI extension when not implemented Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:33   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 15/21] RISC-V: perf: Use config2/vendor table for event to counter mapping Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:23   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 16/21] RISC-V: perf: Add legacy event encodings via sysfs Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:21   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 17/21] RISC-V: perf: Add Qemu virt machine events Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:22   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 18/21] tools/perf: Support event code for arch standard events Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:18   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 19/21] tools/perf: Add RISC-V CounterIDMask event field Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:01 ` [PATCH v6 20/21] TEST(do-not-upstream): fake qemu-virt PMU events for cdeleg counter-mask testing Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:17   ` sashiko-bot
2026-06-09  6:01 ` [PATCH v6 21/21] TEST(do-not-upstream): fake qemu vendor JSON + mapfile entry for CounterIDMask path Atish Patra
2026-06-09  6:01   ` Atish Patra
2026-06-09  6:20   ` 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=20260609061239.160901F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=atish.patra@linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.