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.
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
