netdev - Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Mar 2016 18:16:06 +0000
From:	Scott Wood <scott.wood@....com>
To:	Rob Herring <robh@...nel.org>, Yangbo Lu <yangbo.lu@....com>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	"Jochen Friedrich" <jochen@...am.de>,
	Joerg Roedel <joro@...tes.org>,
	Claudiu Manoil <claudiu.manoil@...escale.com>,
	"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
	Bhupesh Sharma <bhupesh.sharma@...escale.com>,
	"Zhao Qiang" <qiang.zhao@...escale.com>,
	Kumar Gala <galak@...eaurora.org>,
	"Santosh Shilimkar" <ssantosh@...nel.org>,
	Yang-Leo Li <leoyang.li@....com>,
	Xiaobo Xie <xiaobo.xie@....com>
Subject: Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory

On 03/17/2016 12:06 PM, Rob Herring wrote:
> On Wed, Mar 09, 2016 at 06:08:49PM +0800, Yangbo Lu wrote:
>> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
>> since it's used by not only PowerPC but also ARM. And add a specification
>> for 'little-endian' property.
>>
>> Signed-off-by: Yangbo Lu <yangbo.lu@....com>
>> ---
>> Changes for v2:
>> 	- None
>> Changes for v3:
>> 	- None
>> Changes for v4:
>> 	- Added this patch
>> Changes for v5:
>> 	- Modified the description for little-endian property
>> Changes for v6:
>> 	- None
>> ---
>>  Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>  rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>> similarity index 91%
>> rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>> rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
>> index b71b203..07adca9 100644
>> --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
>> +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
>> @@ -25,6 +25,9 @@ Recommended properties:
>>   - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
>>     registers, for those SOCs that have a PAMU device.
>>  
>> + - little-endian : Indicates that the global utilities block is little
>> +   endian. The default is big endian.
> 
> The default is "the native endianness of the system". So absence on an 
> ARM system would be LE.

No.  For this binding, the default is big-endian, because that's what
existed for this device before an endian property was added.

"endianness of the system" is not a well-defined concept.

> This property is valid for any simple-bus device, 

Since when does simple-bus mean anything more than that the nodes
underneath it can be used without bus-specific knowledge?

> so it isn't really required to document per device. You can, but 
> your description had better match the documented behaviour.

Documented where?

In fact, Documentation/devicetree/bindings/common-properties.txt
explicitly says of the endian properties, "If a binding supports these
properties, then the binding should also specify the default behavior if
none of these properties are present."

-Scott