Re: [PATCH V3 3/7] of: Document {little,big,native}-endian bindings

[Peter Hurley <peter@hurleysoftware.com>]

On 11/24/2014 06:36 PM, Kevin Cernekee wrote:
> These apply to newly converted drivers, like serial8250/libahci/...
> The examples were adapted from the regmap bindings document.
> 
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> ---
>  .../devicetree/bindings/common-properties.txt      | 60 ++++++++++++++++++++++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/common-properties.txt
> 
> diff --git a/Documentation/devicetree/bindings/common-properties.txt b/Documentation/devicetree/bindings/common-properties.txt
> new file mode 100644
> index 0000000..21044a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/common-properties.txt
> @@ -0,0 +1,60 @@
> +Common properties
> +
> +The ePAPR specification does not define any properties related to hardware
> +byteswapping, but endianness issues show up frequently in porting Linux to
> +different machine types.  This document attempts to provide a consistent
> +way of handling byteswapping across drivers.
> +
> +Optional properties:
> + - big-endian: Boolean; force big endian register accesses
> +   unconditionally (e.g. ioread32be/iowrite32be).  Use this if you
> +   know the peripheral always needs to be accessed in BE mode.
> + - little-endian: Boolean; force little endian register accesses
> +   unconditionally (e.g. readl/writel).  Use this if you know the
> +   peripheral always needs to be accessed in LE mode.  This is the
> +   default.

There is a fundamental problem with specifying the default in DT bindings.
How can drivers which are currently native-endian support big-endian?

If the driver is converted to support big-endian, every previous
devicetree will be invalid with the new kernel (because those devicetrees
don't specify 'native-endian').

IOW, consider if the default were 'native-endian'. How would the 8250
driver support existing devicetrees?

Regards,
Peter Hurley


> + - native-endian: Boolean; always use register accesses matched to the
> +   endianness of the kernel binary (e.g. LE vmlinux -> readl/writel,
> +   BE vmlinux -> ioread32be/iowrite32be).  In this case no byteswaps
> +   will ever be performed.  Use this if the hardware "self-adjusts"
> +   register endianness based on the CPU's configured endianness.
> +
> +Note that regmap, in contrast, defaults to native-endian.  But this
> +document is targeted for existing drivers, most of which currently use
> +readl/writel because they expect to be accessing PCI/PCIe devices rather
> +than memory-mapped SoC peripherals.  Since the readl/writel accessors
> +perform a byteswap on BE systems, this means that the drivers in question
> +are implicitly "little-endian".
> +
> +Examples:
> +Scenario 1 : CPU in LE mode & device in LE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      native-endian;
> +};
> +
> +Scenario 2 : CPU in LE mode & device in BE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      big-endian;
> +};
> +
> +Scenario 3 : CPU in BE mode & device in BE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      native-endian;
> +};
> +
> +Scenario 4 : CPU in BE mode & device in LE mode.
> +dev: dev@40031000 {
> +	      compatible = "name";
> +	      reg = <0x40031000 0x1000>;
> +	      ...
> +	      little-endian;
> +};
>