linux-kernel - Re: [dtc PATCH V2] Warn on node name unit-address presence/absence mismatch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 27 Sep 2013 10:12:11 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Kumar Gala <galak@...eaurora.org>
CC:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jon Loeliger <jdl@....com>,
	David Gibson <david@...son.dropbear.id.au>,
	Olof Johansson <olof@...om.net>, frowand.list@...il.com,
	Tomasz Figa <tomasz.figa@...il.com>,
	devicetree@...r.kernel.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Stephen Warren <swarren@...dia.com>,
	Rohit Vaswani <rvaswani@...eaurora.org>
Subject: Re: [dtc PATCH V2] Warn on node name unit-address presence/absence
 mismatch

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/