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 9:45 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
>> This doesn't change the behavior of pre-existing drivers that
>> implement the *-endian properties in a different way.  There are not
>> many of these drivers and they can be documented as special cases.
>
> Yeah, ok, as long as there's no expectation that existing drivers
> meet this criteria when they add big-endian support.

The intention is to make it easy for existing drivers with LE register
accesses (i.e. mostly drivers taken from an x86 + PCI environment) to
work on systems with native to BE register accesses.  8250 and USB are
the first two examples of this.

>>> 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?
>>
>> The document aims to provide a consistent way of handling DT
>> endianness properties across (compliant) drivers.  It is confusing if
>> one new driver defaults to little-endian, and another new driver
>> defaults to native-endian.
>
> Ok. How many 4.0 driver + DT submissions that are native-endian are
> declaring this binding?
>
>
>> And since most of the commonly used drivers already implement
>> little-endian MMIO accesses, that is the default.  My personal
>> preference would have been native-endian since that seems more common
>> on the hardware side, but defaulting to little-endian prevents
>> breaking the device tree "ABI" on existing systems.
>
> That was basically my point; there's no way to meet these goals
> for existing, native-endian drivers without breakage (just as there
> would have been no way if native-endian had been the default).

I am not aware of any cases where the new binding needs to be applied
to a driver that is currently native-endian.  Grepping through the
tree for __raw_readl, I see lots of SoC-specific drivers but not a lot
of generic drivers shared by different types of platforms.  Most of
the time we can assume that whoever wrote the driver for their SoC has
figured out the endian situation.  But obviously there could be
exceptions, e.g. new chips using a different endian mode with the same
hardware block.





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

  Powered by Linux