On 2022/11/03 1:48, Krzysztof Kozlowski wrote:
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@14006000 {
+ 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.
Okay, however, if there are no examples where the second is "status",
I think it is better to follow the many descriptions for new additions.
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
I think it is reasonable to arrange the properties in order of importance.
I'll put "reg" second in this addition in the next.
Thank you,
---
Best Regards
Kunihiko Hayashi
