linux-kernel - Re: [PATCH 4/4] arm64: dts: uniphier: Add NX1 SoC and boards support

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: <f1b5e138-e708-8aeb-9b59-96403f996fbd@linaro.org>
Date:   Wed, 2 Nov 2022 12:48:54 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
        Masami Hiramatsu <mhiramat@...nel.org>
Cc:     soc@...nel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] arm64: dts: uniphier: Add NX1 SoC and boards support

On 01/11/2022 05:02, Kunihiko Hayashi wrote:
> Hi Krzysztof,
> 


>>> +				compatible = "socionext,uniphier-nx1-clock";
>>> +				#clock-cells = <1>;
>>> +			};
>>> +
>>> +			sys_rst: reset {
>>
>> reset-controller
>>
>>> +				compatible = "socionext,uniphier-nx1-reset";
>>> +				#reset-cells = <1>;
>>> +			};
>>> +
>>> +			watchdog {
>>> +				compatible = "socionext,uniphier-wdt";
>>> +			};
>>> +
>>> +			pvtctl: thermal-sensor {
>>> +				compatible = "socionext,uniphier-nx1-thermal";
>>> +				interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
>>> +				#thermal-sensor-cells = <0>;
>>> +				socionext,tmod-calibration = <0x0f22 0x68ee>;
>>> +			};
>>> +		};
>>> +
>>> +		spi0: spi@...06000 {
>>> +			compatible = "socionext,uniphier-scssi";
>>> +			status = "disabled";
>>> +			reg = <0x14006000 0x100>;
>>
>> Reg is second property. Status goes last. The same in other nodes.
> 
> Hmm, I've put "status" here according to the existing (uniphier's) DT policy
> and this should rewrite the policy. Is there documentation somewhere that
> recommends the order? Or, should I refer to previous comments?

Hm, your decision (as arch maintainer) is then preferred, not mine.
Although it is quite unusual to find status, not reg, as the second
property.

compatible followed by reg is not documented anywhere, it's just the
most used style. And actually most sensible as it answers to questions
from highest importance to lowest:
1. What is this device? compatible
2. Where is it? Does it match unit address? reg
3. all other properties
4. Is it off or on? status as optional property

Best regards,
Krzysztof