On Monday 09 May 2016 14:11:23 John Youn wrote: > On 5/9/2016 1:39 PM, Arnd Bergmann wrote: > > > The systems are not a particular endianess, only the current state > > of the CPU is, and that may change independent of the way the > > hardware block got synthesized. We don't support swapping endianess > > at runtime in Linux, but the system normally doesn't care what we > > run. > > > > The normal behavior is for the register contents to be read as > > little-endian, and then swapped on big-endian kernel builds to > > match what the kernel expects. > > > > MIPS is a special case here, because the endianess of the CPU > > core is fixed in hardware (or using a strapping pin) and is often > > tied to the endianess of all the IP blocks. There are a couple > > of other architectures like this (e.g. ARM ixp4xx, but none of the > > modern ARM systems). > > Ok thanks. What you're saying is clear now. > > Is there a standard way to handle this? Must all drivers either check > some endianness configuration or do a runtime check? There are four common approaches: 1 hardcode a particular endianess because an IP block is always used the same way 2 pick the right endianess at compile-time because we know what we are building for (typically by CPU architecture, but there are some other ways) 3 do runtime configuration based on a DT property or platform data 4 do automatic runtime configuration based on well-known register contents Approach 1 is the most common, in particular as most IP blocks are not configurable and are not used on big-endian MIPS machines. Approach 4 as implemented by Christian Lamparter's patch is the most reliable way, and probably makes most sense for DesignWare IP blocks in general, because they are configurable and may get used in all kinds of systems. Approaches 2 and 3 are somewhat inferior because you have to rely on everyone else doing it the way you planned, but 2 is particularly easy and 3 is used when there is no obvious way to detect endianess of the device. The patch I suggested would be approach 2, and as Felipe correctly mentioned, it is not ideal, but it may be more appropriate for backports to the 4.4-longterm, 4.5-stable and 4.6-stable kernels than the more elaborate patch we are now discussing. Arnd
