On Wed, Oct 31, 2018 at 12:03:14PM -0700, Frank Rowand wrote: > 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? Only if the (parent) base address of the first range is 0. Otherwise the unit address shuold be that first base address. > 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 agree, but.. > 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. .. I agree there too. > Rationale: this is consistent with the rules for the "reg" property. A little history here. Traditionally the unit-address is bound to 'reg' alone, never ranges (note that in actual OF, the unit-address isn't stored anywhere, it's generated at run time from 'reg'). This gets weird, however, if you have multiple, similar passive bridges on a bus translating different address windows to subordinate buses. Because they're passive, they have no control registers, hence no sensible value for 'reg'. So, how do we distinguish them? The obvious choice is by the translated address range - i.e. by the 'ranges' property. This was the original rationale for using 'ranges' to generate the unit address if 'reg' wasn't present. I concur with Frank that it makes sense to formalize it into the spec. > 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. I disagree on that detail. An empty 'ranges' indicates an identity mapping, so in this case unit-address should be "@0", well, unless the parent bus has a different text encoding that would make sense for an indentity mapping. > 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. Not correct, empty 'ranges' is equivalent to a ranges value with multiple chunks exactly covering the whole address space (parent & child #address-cells must be equal in this case). > 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. Yes, 'reg' always takes priority over ranges. > Rational: the first entry in the "ranges" property is not required to > match the first entry in the "reg" property. In fact, they basically *can't* be the same: that would mean the device decodes those addresses as registers *and* translates them to a child bus. > 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 > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
