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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux