On Mon, Mar 2, 2015 at 5:14 AM, Peter Hurley <[email protected]> wrote: > 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 <[email protected]> >> --- >> .../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?
Correct. This scheme is intended for drivers like 8250 and libahci which currently default to little-endian by virtue of using readl/writel for MMIO accesses. Drivers that default to native-endian should specify that in their bindings documents, similar to Documentation/devicetree/bindings/regmap/regmap.txt. In practice we might not see too many cases of native-endian drivers that need to be converted to work in forced big-endian mode anyway, because most uses of the __raw_* accessors are found in SoC-specific code. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
