On 09/27/2013 09:39 AM, Kumar Gala wrote: > > On Sep 26, 2013, at 8:30 PM, Benjamin Herrenschmidt wrote: > >> On Thu, 2013-09-26 at 17:12 -0600, Stephen Warren wrote: >>> Well, ePAPR seems pretty specific that unit address and reg are >>> related, >>> but says nothing about ranges in the section on node naming, nor about >>> node naming in the section about ranges. >>> >>> I'd claim that the existing PPC trees are nonconforming, and should be >>> fixed too:-) >> >> This is tricky, we should probably fix ePAPR here. > > I'll poke Stuart to see what's going w/updating ePAPR. > >> If you have a "soc" bus covering a given range of addresses which it >> forwards to its children devices but doesn't have per-se its own >> registers in that area, then it wouldn't have a "reg" property. I would >> thus argue that in the absence of a "reg" property, if a "ranges" one is >> present, the "parent address" entry in there is an acceptable substitute >> for the "reg" property as far as unit addresses are concerned. > > Either we update the section in general about 'ranges' or at least update the simple-bus binding to state that rules about the node name. I think you'd need to update section 2.2.1.1 which specifies the node name rather than any other section. The wording in 2.2.1.1 certainly states that buses can impose specific rules on the value/format of the unit address in the node name, but I'm not convinced it allows buses to override the rules that control the presence/absence of the unit address. In other words, I would simply replace: The unit-address must match the first address specified in the reg property of the node with: 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 match the first address specified in the ranges property of the node. and: If the node has no reg property, with: If the node has no reg property or ranges property, -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
