A question was raised in the devicetree irc channel: I am getting a warning "node has a reg or ranges property, but no unit name" the node in question is soc node and has no reg < > but has ranges < > so I fixed it up by doing soc@0, is this the right way to go about it? To the best of my understanding, the check is not consistent with the Devicetree Specification, v0.2. The commit that added this check to dtc notes the same wording in the ePAPR as I noted in the Devicetree Specification, but then concluded "ePAPR is not clear about it (commit c9d9121683b3, "Warn on node name unit-address presence/absence mismatch"). I think that the check is reasonable, and that the specification should be updated to match the check. This email is meant to solicit agreement or disagreement before I send a patch to the specification. Section "2.2.1 Node Names" states: The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree. I do not see any way to read that to allow a unit-address in the node name if the node does not contain a "reg" property. I would like to change 2.2.1 to require the unit-address if the node contains a "ranges" with a value that is not <empty>. In this case the unit-address must match the first parent-bus-address specified in the "ranges" property. Rationale: this is consistent with the rules for the "reg" property. I would like to further note in the change to 2.2.1 that the unit-address must be omitted if the node does not contain a "reg" property, but does contain a "ranges" property with an <empty> value. Rationale: the "ranges" property in this case does not specify a value that could be used for unit-address, and there is no other source that would specify the value. In the case that a node contains both a "reg" property and a "ranges" property with a value that is not empty, the "reg" property rule is applied to the unit-address and the "ranges" property rule is ignored. Rational: the first entry in the "ranges" property is not required to match the first entry in the "reg" property. This extra rule precludes ambiguity of whether to use the address from "reg" or from "ranges" for the unit-address. For the curious, a real life example of this is in the Linux kernel source tree, for node "soc" in arch/arm64/boot/dts/qcom/msm8916.dtsi. This file is included by either apq8016-sbc.dts or msm8916-mtp.dts. -Frank
