usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4
Benjamin Herrenschmidt
benh at kernel.crashing.org
Tue May 10 08:37:52 AEST 2016
On Mon, 2016-05-09 at 17:08 +0200, Arnd Bergmann wrote:
>
> Unfortunately, I don't see any way this could be done in MIPS specific
> code: There is typically a byteswap between the internal bus and the PCI
> bus on big-endian MIPS systems, so the PCI MMIO ends up being little-endian,
Ugh ... not exactly, re-watch my talk on the matter :-) While there is
a specific lane wiring to preserve byte addresss, in the end it's the
end device itself that is either BE or LE. Regardless of any "bus
endianness".
> which matches the expected behavior of readl/writel. However, drivers
> for non-PCI devices often use the same readl/writel accessors because
> that is how it's done on ARMv6/ARMv7.
Even then, you can have on-SoC (non-PCI) devices that also have a
different endianness from the main CPU. How does it work on ARM for
example ? The device endianness should be fixed, regardless of the
endianness of the core, no ?
> Doing it hardcoded by architecture is just the simplest way to deal
> with it, working on the assumption that nothing actually needs the
> runtime detection that Ben suggested.
No, it's not an archicture problem. It's a problem specific to that one
SoC that the device was synthetized to be a certain endian while it was
synthetized differently on another SoC... that also happens to be a
different architecture. But doesn't have to.
For example, we had in the past cases of both LE and BE EHCI
implementations on the same architecture (PowerPC).
> Detecting the endianess of the
> device is probably the best future-proof solution, but it's also
> considerably more work to do in the driver, and comes with a
> tiny runtime overhead.
The runtime overhead is probably non-measurable compared with the cost
of the actual MMIOs.
Cheers,
Ben.
More information about the Linuxppc-dev
mailing list