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: <20ae21a6-74b0-ff99-80d9-1a0ce2cc1aa5@gmail.com>
Date:   Thu, 2 Apr 2020 22:10:21 +0200
From:   Johan Jonker <jbx6244@...il.com>
To:     Helen Koike <helen.koike@...labora.com>
Cc:     dafna.hirschfeld@...labora.com, devel@...verdev.osuosl.org,
        devicetree@...r.kernel.org, ezequiel@...labora.com,
        heiko@...ech.de, hverkuil-cisco@...all.nl,
        karthik.poduval@...il.com, kernel@...labora.com,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        linux-rockchip@...ts.infradead.org, mark.rutland@....com,
        robh+dt@...nel.org
Subject: Re: [PATCH 4/4] arm64: dts: rockchip: add isp0 node for rk3399

On 4/2/20 9:46 PM, Helen Koike wrote:
> 
> 
> On 4/2/20 2:20 PM, Johan Jonker wrote:
>> Hi Helen,
>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> index fc0295d2a65a1..815099a0cd0dd 100644
>>> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>> @@ -1718,6 +1718,33 @@ vopb_mmu: iommu@...03f00 {
>>>  		status = "disabled";
>>>  	};
>>>  
>>> +	isp0: isp0@...10000 {
>>> +		compatible = "rockchip,rk3399-cif-isp";
>>> +		reg = <0x0 0xff910000 0x0 0x4000>;
>>> +		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>;
>>> +		clocks = <&cru SCLK_ISP0>,
>>> +			 <&cru ACLK_ISP0>, <&cru ACLK_ISP0_WRAPPER>,
>>> +			 <&cru HCLK_ISP0>, <&cru HCLK_ISP0_WRAPPER>;
>>> +		clock-names = "clk_isp",
>>> +			      "aclk_isp", "aclk_isp_wrap",
>>> +			      "hclk_isp", "hclk_isp_wrap";
>>
>>> +		power-domains = <&power RK3399_PD_ISP0>;
>>> +		iommus = <&isp0_mmu>;
>>> +		phys = <&mipi_dphy_rx0>;
>>> +		phy-names = "dphy";
>>
>> Maybe a little sort? But keep rest as it is. Also in example.
>>
>> 		iommus = <&isp0_mmu>;
>> 		phys = <&mipi_dphy_rx0>;
>> 		phy-names = "dphy";
>> 		power-domains = <&power RK3399_PD_ISP0>;
> 
> Are you proposing only to move power-domains after phy? And keep the rest?
> What is the main logic?

There is no hard rule... It mostly depend on Heiko...

For nodes:
Sort things without reg alphabetical first,
then sort the rest by reg address.

Inside nodes:
If exists on top: compatible, reg and interrupts.
In alphabetical order the required properties.
Then in alphabetical order the other properties.
And as last things that start with '#' in alphabetical order.

> 
> Thanks
> Helen
> 
>>
>>> +
>>> +		ports {
>>> +			#address-cells = <1>;
>>> +			#size-cells = <0>;
>>> +
>>> +			port@0 {
>>
>>> +				#address-cells = <1>;
>>> +				#size-cells = <0>;
>>> +				reg = <0>;
>>
>> Move reg above #address-cells. Change that in example as well.
>>
>> 				reg = <0>;
>> 				#address-cells = <1>;
>> 				#size-cells = <0>;
>>
>>> +			};
>>> +		};
>>> +	};
>>> +
>>>  	isp0_mmu: iommu@...14000 {
>>>  		compatible = "rockchip,iommu";
>>>  		reg = <0x0 0xff914000 0x0 0x100>, <0x0 0xff915000 0x0 0x100>;
>>> -- 
>>> 2.26.0
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ