Re: [RESEND PATCH 2/4] asm-generic: io: don't perform swab during{in,out} string functions

[Benjamin Herrenschmidt]

On Sun, 2012-10-28 at 10:28 +0100, Geert Uytterhoeven wrote:

> > This is due to how the PCI bus is wired to the CPU bus, which is called
> > "byte address invariant". When doing a read of your byte 0, the CPU will
> > effectively read 0 with byte enables picking 48. Since the CPU wants
> > the first byte in the MSB, the bus must be wired up to the CPU such that
> > the MSB is the first byte in address order.
> 
> According to
> https://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/WritingPCIDrivers/endianness/endianness.html
> 
> "Byte-invariant addressing is a property of the bus bridge itself."

Right.

> and
> 
> "From the software designerâs perspective, this means that the
> hardware does not byte swap the data. However, from the hardware
> designerâs perspective, the hardware must byte swap all data."
> 
> So this depends on a correct hardware implementation in the PCI
> host bridge?

Correct. It is also how AMBA works on BE for example, it's generally
accepted that this is the "right" way to wire a bridge.

> > Then something is horribly wrong in those m68k setups :-) Either in the
> > way the busses are wired or in your implementation of either inw or
> > insw.
> 
> On (classic) m68k all of this is not about PCI (Atari Hades PCI is no
> more), but about ISA and PCMCIA. I.e. no PCI host bridge with a modern
> understanding of how it should be wired correctly on a big endian platform.

There's nothing modern about byte address invariance. The same rule
applies to ISA and PCMCIA just the same. It's possible that your
specific m68k platforms were designed by monkeys on crack, which seems
to be a common breed among HW designers, but that doesn't make it
right :-)

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/