Re: [PATCH RFC] dt-bindings: perf: riscv,pmu: Add interrupts-extended property

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Overloading `interrupts-extended` as the sole CPU affinity map fails when PMU interrupts are optional.
--

commit c04ae2b471021dd39ca8ccf1e788362245660a9d
Author: Eric Lin <eric.lin@sifive.com>

dt-bindings: perf: riscv,pmu: Add interrupts-extended property

This commit adds the interrupts-extended property to the riscv,pmu binding
to define the connection between the PMU overflow interrupt and the CPU
local interrupt controller. It also notes this property is used by software
to associate a PMU node with a specific CPU on heterogeneous systems.

> diff --git a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
> --- a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
> +++ b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
> @@ -34,6 +34,13 @@ properties:
>    compatible:
>      const: riscv,pmu
>  
> +  interrupts-extended:
> +    minItems: 1
> +    maxItems: 4095
> +    description:
> +      Specifies the interrupt-parent and local interrupt index for each CPU's
> +      PMU counter overflow. Each item points to a riscv,cpu-intc node.

[Severity: Medium]
Does overloading interrupts-extended as the sole CPU affinity map cause
failures on systems without PMU interrupts?

If a heterogeneous RISC-V SoC lacks the optional Sscofpmf extension, it
would omit the interrupts-extended property entirely. Without this property,
it seems the OS would have no mechanism to determine which PMU node belongs
to which CPU, potentially breaking perf functionality on such hardware.

Would it be safer to introduce a dedicated affinity property to prevent
future fragmentation when PMU interrupts are absent?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-pmu-dt-property-v1-1-a7a7737afb72@sifive.com?part=1