On 03/02/2015 09:56 AM, Kevin Cernekee wrote: > On Mon, Mar 2, 2015 at 5:14 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> 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 <cernekee@xxxxxxxxx> >>> --- >>> .../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. Which effectively means if a user can't upgrade their devicetree, they can't upgrade their kernel. I don't think that flies. It's exactly this kind of stuff that prompted Jonathan Corbet's article, "Device trees as ABI" http://lwn.net/Articles/561462 Why not leave the default unspecified? Regards, Peter Hurley > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
