linux-kernel - 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]

Message-ID: <CADRPPNRPP0cxrJT13OR+dAWuw8m0mr0=VJLY+JyTO=QsB_vVUw@mail.gmail.com>
Date:	Thu, 17 Mar 2016 16:33:35 -0500
From:	Leo Li <pku.leo@...il.com>
To:	Rob Herring <robh@...nel.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Zhao Qiang <qiang.zhao@...escale.com>, xiaobo.xie@....com,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	linux-clk <linux-clk@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Bhupesh Sharma <bhupesh.sharma@...escale.com>,
	Joerg Roedel <joro@...tes.org>, scott.wood@....com,
	Claudiu Manoil <claudiu.manoil@...escale.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Yangbo Lu <yangbo.lu@....com>,
	Santosh Shilimkar <ssantosh@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	netdev <netdev@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Li Yang <leoyang.li@....com>,
	Linux IOMMU <iommu@...ts.linux-foundation.org>,
	Kumar Gala <galak@...eaurora.org>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory

On Thu, Mar 17, 2016 at 12:57 PM, Rob Herring <robh@...nel.org> wrote:
> On Thu, Mar 17, 2016 at 12:11 PM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
>>> > 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".
>>
>> This may be what is currently documented, but not what we are doing
>> in practice, as there is no "native endianess" for either PowerPC or
>> ARM -- both allow running big-endian or little-endian kernels and the
>> device registers are fixed.
>
> Notice I said system, not architecture. The way the device registers
> are fixed is what I mean by native endianness.

I think sometimes it's also hard to define the native endianess of the
system too.  For whatever reason, we have hardware that having
big-endian registers on some on-chip devices but using little-endian
registers on other devices.  Even if all the devices on certain
hardware use registers of the same endianess, it is also hard for the
device driver to know what the native endianess really is.

>
> If the purpose of adding this property now is to support GUTS on the
> ARM SoCs, then I'd argue using this property is probably wrong. If the
> PPC systems are designed with BE device registers and ARM systems with
> LE, then this property is not needed.
>
>> I think the property here is fine.
>
> Unless you have studied the FSL ARM based SoCs, then there is not
> enough information here to tell.

Recent FSL ARM SoCs seems to have more weird endianess issue. :( The
same IP could have registers of different endianess on different ARM
SoCs.  That why we need to define the endianess explicitly in device
tree.

Regards,
Leo