| Common properties | 
 | ================= | 
 |  | 
 | Endianness | 
 | ---------- | 
 |  | 
 | The Devicetree 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. | 
 |  - 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. | 
 |  | 
 | If a binding supports these properties, then the binding should also | 
 | specify the default behavior if none of these properties are present. | 
 | In such cases, little-endian is the preferred default, but it is not | 
 | a requirement.  The of_device_is_big_endian() and of_fdt_is_big_endian() | 
 | helper functions do assume that little-endian is the default, because | 
 | most existing (PCI-based) drivers implicitly default to LE by using | 
 | readl/writel for MMIO accesses. | 
 |  | 
 | 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; | 
 | }; | 
 |  | 
 | Daisy-chained devices | 
 | --------------------- | 
 |  | 
 | Many serially-attached GPIO and IIO devices are daisy-chainable.  To the | 
 | host controller, a daisy-chain appears as a single device, but the number | 
 | of inputs and outputs it provides is the sum of inputs and outputs provided | 
 | by all of its devices.  The driver needs to know how many devices the | 
 | daisy-chain comprises to determine the amount of data exchanged, how many | 
 | inputs and outputs to register and so on. | 
 |  | 
 | Optional properties: | 
 |  - #daisy-chained-devices: Number of devices in the daisy-chain (default is 1). | 
 |  | 
 | Example: | 
 | gpio@0 { | 
 | 	      compatible = "name"; | 
 | 	      reg = <0>; | 
 | 	      gpio-controller; | 
 | 	      #gpio-cells = <2>; | 
 | 	      #daisy-chained-devices = <3>; | 
 | }; |