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.
