linux-kernel - Re: [PATCH 2/2] dt-bindings/perf: Drop irqs for clock domains without a PMU instance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5f260792-40f2-4a54-a5d1-45644bc9012b@arm.com>
Date: Mon, 26 Jan 2026 17:09:43 +0000
From: Robin Murphy <robin.murphy@....com>
To: Baisheng Gao <baisheng.gao@...soc.com>, Will Deacon <will@...nel.org>,
 Mark Rutland <mark.rutland@....com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Cc: cixi.geng@...ux.dev, hao_hao.wang@...soc.com,
 linux-arm-kernel@...ts.infradead.org, linux-perf-users@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings/perf: Drop irqs for clock domains without
 a PMU instance

On 2026-01-26 3:30 am, Baisheng Gao wrote:
> No need to specify the interrupts for the clock domains without a
> PMU instance.

Yes there is a need, because it's what the binding has already defined 
and systems are already implementing, so breaking compatibility at this 
point more than a year after its introduction is not really acceptable. 
And although there's no strict requirement for the DT and ACPI bindings 
to be equivalent, in this case they currently are, and it doesn't seem 
like you've accounted for ACPI here either.

Fact is, the Arm NI-700, NI-710AE, NoC S3 and SI L1 designs do all 
define <CLKNAME>_nPMUINTERRUPT outputs for each <CLKNAME> domain, and 
the intent of the binding was always to describe the hardware. If it's 
the case that one or more of those interrupts are not wired up at all 
(and presumably the corresponding PMU is never exposed to Non-Secure, 
since it's unlikely to be useful), then at worst it's reasonable to use 
dummy entries to pad the array.

If on the other hand you really have got something that is mangled to 
the point of not being compatible with the stock Arm designs, then it 
most likely warrants its own binding.

Thanks,
Robin.

> Signed-off-by: Baisheng Gao <baisheng.gao@...soc.com>
> ---
>   Documentation/devicetree/bindings/perf/arm,ni.yaml | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/perf/arm,ni.yaml b/Documentation/devicetree/bindings/perf/arm,ni.yaml
> index d66fffa256d5..40a5b8929ef2 100644
> --- a/Documentation/devicetree/bindings/perf/arm,ni.yaml
> +++ b/Documentation/devicetree/bindings/perf/arm,ni.yaml
> @@ -20,7 +20,8 @@ properties:
>     interrupts:
>       minItems: 1
>       maxItems: 32
> -    description: Overflow interrupts, one per clock domain, in order of domain ID
> +    description: Overflow interrupts, one per clock domain which has a PMU
> +      instance, in order of domain ID.
>   
>   required:
>     - compatible