On Wed, Apr 23, 2014 at 07:46:34AM +0100, Xiubo Li wrote:
> Signed-off-by: Xiubo Li <Li.Xiubo@xxxxxxxxxxxxx>
> ---
> .../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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
