linux-kernel - Re: [PATCH 08/14] dt-bindings: dma: dma350: Document interrupt-names

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7230cb2a-2a66-49d4-bb37-b0df2a79f7d0@arm.com>
Date: Fri, 29 Aug 2025 12:08:41 +0100
From: Robin Murphy <robin.murphy@....com>
To: Jisheng Zhang <jszhang@...nel.org>, Vinod Koul <vkoul@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>
Cc: dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/14] dt-bindings: dma: dma350: Document interrupt-names

On 2025-08-23 4:40 pm, Jisheng Zhang wrote:
> Currently, the dma350 driver assumes all channels are available to
> linux,

No, it doesn't - the CH_CFG_HAS_CMDLINK check is designed to safely skip 
channels reserved for Secure world (or that don't exist due to an FVP 
bug...), since their CH_BUILDCFG1 will as zero.

> this may not be true on some platforms, so it's possible no
> irq(s) for the unavailable channel(s). What's more, the available
> channels may not be continuous. To handle this case, we'd better
> get the irq of each channel by name.

Unless you're suggesting these channels physically do not have their 
IRQs wired up to anything at all, what's wrong with describing the 
hardware in DT? Linux won't request IRQs for channels it isn't actually 
using, and nor should any other reasonable DT consumer - precisely 
because channels *can* be arbitrarily taken by the Secure world, and 
that can be entirely dynamic based on firmware configuration even for a 
single hardware platform.

And even in the weird case that some channel literally has no IRQ, my 
thought was we'd just have a placeholder entry in the array, such that 
attempting to request it would fail.

Thanks,
Robin.

> Signed-off-by: Jisheng Zhang <jszhang@...nel.org>
> ---
>   Documentation/devicetree/bindings/dma/arm,dma-350.yaml | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> index 429f682f15d8..94752516e51a 100644
> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
> @@ -32,6 +32,10 @@ properties:
>         - description: Channel 6 interrupt
>         - description: Channel 7 interrupt
>   
> +  interrupt-names:
> +    minItems: 1
> +    maxItems: 8
> +
>     "#dma-cells":
>       const: 1
>       description: The cell is the trigger input number
> @@ -40,5 +44,6 @@ required:
>     - compatible
>     - reg
>     - interrupts
> +  - interrupt-names
>   
>   unevaluatedProperties: false