On 12/16/14 21:40, Paolo Bonzini wrote: > On 16/12/2014 21:06, Laszlo Ersek wrote:
>> You flipped the combined ops to LE in commit 6fdf98f2 (and, apparently, >> I reviewed it). Shouldn't we do the same for the standalone selector? > > No. The standalone selector is used as MMIO, and the BE platforms > expect the platform to be big-endian. The combined ops are only used on > ISA ports, where the firmware expects them to be little-endian (as > mentioned in the commit message). > > That said, the standalone selector is used by BE platforms only, so we > know that the standalone selector is always DEVICE_BIG_ENDIAN. This series exposes the standalone selector (as MMIO) to ARM guests as well; and in "Documentation/devicetree/bindings/arm/fw-cfg.txt" for the kernel I'm saying that the selector is little endian. Therefore I think that the standalone selector is not only (going to be) used by BE platforms (or I don't understand your above statement correctly). But, the current (and to be preserved) NATIVE_ENDIAN setting still matches what I say in "Documentation/devicetree/bindings/arm/fw-cfg.txt", because, Peter said: > NATIVE_ENDIAN means "same order as the CPU's main data bus's natural > representation". (Note that this is not necessarily the same as "the > endianness the CPU currently has"; on ARM you can flip the CPU between > LE and BE at runtime, which is basically inserting a byte-swizzling > step between data accesses and the CPU's data bus, which is always LE > for ARMv7+.) In other words, the standalone selector is NATIVE_ENDIAN, but in the description of the *ARM* bindings, we can simply say that it's little endian. Is that right? Thanks Laszlo > > So if you want, you can make the standalone selector and the standalone > datum BE and swap them in the firmware. If the suggestion doesn't make > you jump up and down, I understand that. :) > > Paolo >
