linux-kernel - Re: [PATCH v2 2/3] arm64: dts: rockchip: Add DMA controller for RK3528

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: <02f6e0e0-9cd8-425c-bad2-f061b601fdcd@kwiboo.se>
Date: Tue, 1 Apr 2025 19:43:33 +0200
From: Jonas Karlman <jonas@...boo.se>
To: Yao Zi <ziyao@...root.org>, Chukun Pan <amadeus@....edu.cn>
Cc: Rob Herring <robh@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/3] arm64: dts: rockchip: Add DMA controller for
 RK3528

On 2025-04-01 19:35, Yao Zi wrote:
> On Tue, Apr 01, 2025 at 06:00:19PM +0800, Chukun Pan wrote:
>> Add DMA controller dt node for RK3528 SoC.
>>
>> Signed-off-by: Chukun Pan <amadeus@....edu.cn>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3528.dtsi | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3528.dtsi b/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>> index 7f1ffd6003f5..c366766ee3f5 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>> @@ -493,6 +493,24 @@ sdhci: mmc@...f0000 {
>>  			status = "disabled";
>>  		};
>>  
>> +		dmac: dma-controller@...60000 {
>> +			compatible = "arm,pl330", "arm,primecell";
>> +			reg = <0x0 0xffd60000 0x0 0x4000>;
>> +			clocks = <&cru ACLK_DMAC>;
>> +			clock-names = "apb_pclk";
>> +			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
>> +			arm,pl330-periph-burst;
> 
> Should this be moved above "clocks" line to sort the properties?

Not preferred according to [1], vendor-prefixed props is ordered after
non-vendor-prefixed props.

"""
The following order of properties in device nodes is preferred:
- "compatible"
- "reg"
- "ranges"
- Standard/common properties (defined by common bindings, e.g. without
  vendor-prefixes)
- Vendor-specific properties
- "status" (if applicable)
- Child nodes, where each node is preceded with a blank line

The "status" property is by default "okay", thus it can be omitted.

The above-described ordering follows this approach:
- Most important properties start the node: compatible then bus
  addressing to match unit address.
- Each node will have common properties in similar place.
- Status is the last information to annotate that device node is or is
  not finished (board resources are needed).
"""

[1] https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node

Regards,
Jonas

> 
> Thanks,
> Yao Zi
> 
>> +			#dma-cells = <1>;
>> +		};
>> +
>>  		pinctrl: pinctrl {
>>  			compatible = "rockchip,rk3528-pinctrl";
>>  			rockchip,grf = <&ioc_grf>;
>> -- 
>> 2.25.1
>>