| Common properties | |
| ================= | |
| Endianness | |
| ---------- | |
| The Devicetree Specification does not define any properties related to hardware | |
| byte swapping, but endianness issues show up frequently in porting drivers to | |
| different machine types. This document attempts to provide a consistent | |
| way of handling byte swapping 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 big endian (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 little endian (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 byte swaps | |
| 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. Some implementations assume that little-endian is | |
| the default, because most existing (PCI-based) drivers implicitly | |
| default to LE for their 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>; | |
| }; |