[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140423084009.GB30036@e106331-lin.cambridge.arm.com>
Date: Wed, 23 Apr 2014 09:40:09 +0100
From: Mark Rutland <mark.rutland@....com>
To: Xiubo Li <Li.Xiubo@...escale.com>
Cc: "broonie@...nel.org" <broonie@...nel.org>,
"rob@...dley.net" <rob@...dley.net>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
Pawel Moll <Pawel.Moll@....com>,
"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
"galak@...eaurora.org" <galak@...eaurora.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2 2/3] regmap: Add the DT binding documentation for
endianness
On Wed, Apr 23, 2014 at 07:46:34AM +0100, Xiubo Li wrote:
> Signed-off-by: Xiubo Li <Li.Xiubo@...escale.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.
--
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/
Powered by blists - more mailing lists