Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for endianness

[Mark Rutland <mark.rutland@arm.com>]

On Wed, Apr 23, 2014 at 07:46:34AM +0100, Xiubo Li wrote:
> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> ---
>  .../bindings/regmap/regmap-endianness.txt          | 48 ++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> 
> diff --git a/Documentation/devicetree/bindings/regmap/regmap-endianness.txt b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> new file mode 100644
> index 0000000..1d838c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regmap/regmap-endianness.txt
> @@ -0,0 +1,48 @@
> +Device-Tree bindings for regmap endianness

As regmap is a Linux internal detail, I don't see why it needs to leak
into bindings.

> +Required properties:
> +- regmap-reg-endian: register endianness, see ../endianness/endianness.txt
> +  for detail.
> +- regmap-val-endian: value endianness, see ../endianness/endianness.txt for

I'm not familiar with regmap. What is the difference between register
and value endianness?

> +  detail.
> +
> +The Endianness flags supported by regmap:
> +DT properties           Macros
> +----------------------------------------
> +    'le'          REGMAP_ENDIAN_LITTLE
> +    'be'          REGMAP_ENDIAN_BIG
> +    'native'      REGMAP_ENDIAN_NATIVE
> +    Absent        REGMAP_ENDIAN_DEFAULT

As mentinoned earlier, I think we should stick to the common convention
of device-specific {big,little}-endian{,-*} boolean properties. The
common case might just be a simple big-endian property, with LE assumed
(or the inverse with a little-endian property).

Cheers,
Mark.