linux-kernel - RE: [PATCHv4 2/2] regmap: add DT endianness binding support.

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]

Message-ID: <00adcdedcfdf4c828d5fd5a8dd7e28bd@BY2PR03MB505.namprd03.prod.outlook.com>
Date:	Mon, 19 May 2014 04:11:35 +0000
From:	"Li.Xiubo@...escale.com" <Li.Xiubo@...escale.com>
To:	Mark Rutland <mark.rutland@....com>
CC:	"broonie@...nel.org" <broonie@...nel.org>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"rdunlap@...radead.org" <rdunlap@...radead.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCHv4 2/2] regmap: add DT endianness binding support.

> Subject: Re: [PATCHv4 2/2] regmap: add DT endianness binding support.
> 
> On Fri, May 09, 2014 at 03:04:33AM +0100, Xiubo Li wrote:
> > For many drivers which will support rich endianness of CPU<-->Dev
> > need define DT properties by itself without the binding support.
> >
> > The endianness using regmap:
> > Index    CPU       Device     Endianess flag for DT bool property
> > ------------------------------------------------------------
> > 1        LE        LE         -
> > 2        LE        BE         'big-endian-{val,reg}'
> > 3        BE        BE         -
> > 4        BE        LE         'little-endian-{val,reg}'
> 
> Get rid of the CPU column. It has precisely _nothing_ to do with the
> device.
> 
> If you happen to have a device that can be integrated with varying
> endianness, the endianness should be described regardless of whether
> this happens to be the same as the CPU endianness. The kernel can then
> choose to do the right thing regardless.
> 
> Assuming LE or BE by default is sane if most implementations are one
> rather than the other. Probing and figuring it out dynamically is also
> fine. Assuming that it's the same as the kernel is broken in general,
> and should be avoided -- those cases _require_ a *-endian property to
> work if the CPU can function in either endianness.
> 

Yes, If my understanding is correct, if we need inverting the bytes order, 
should be add one property here, regardless of the CPU's endianesses.


> > Please see the following documetation for detail:
> >     Documentation/devicetree/bindings/endianness/endianness.txt
> 
> I don't think this is sufficient. That document describes the preferred
> idiom, not the meaning w.r.t. a specific binding.
> 
> [...]
> 
> > +	case REGMAP_ENDIAN_REG:
> > +		if (of_property_read_bool(np, "big-endian-reg"))
> > +			*endian = REGMAP_ENDIAN_BIG;
> > +		else if (of_property_read_bool(np, "little-endian-reg"))
> > +			*endian = REGMAP_ENDIAN_LITTLE;
> 
> While this follows the guidelines you've added, context is still
> required to understand precisely what this means. We need a binding
> document describing what *-endian-reg means for this binding (i.e. what
> does -reg cover? All registers? some? buffers?).
> 

Yes, for now the 'reg' is for all registers of the device.
And the 'val' is for all the values and buffers of the device.

@Mark Brown,
Do you have any correction here ?


> Imagine I added a little-endian-foo property. You'd be able to reason
> that something is little endian, but you'd have no idea of precisely
> what without reading documentation or code. As not everyone wants to
> read several thousand lines of Linux kernel code to write a dts we
> require documentation.
> 

@Mark Rutland, @Mark Brown,
Yes, where should I locate the documentation ?
Is Documentation/devicetree/bindings/regmap/ okay ?


Thanks,

BRs
Xiubo


> > +	case REGMAP_ENDIAN_VAL:
> > +		if (of_property_read_bool(np, "big-endian-val"))
> > +			*endian = REGMAP_ENDIAN_BIG;
> > +		else if (of_property_read_bool(np, "little-endian-val"))
> > +			*endian = REGMAP_ENDIAN_LITTLE;
> 
> Likewise.
> 
> Cheers,
> Mark.
--
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/