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