Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

From
Arnd Bergmann <arnd@arndb.de>
Date
2016-05-09 15:09:17
Also in
linux-mips, lkml
Reply to
Felipe Balbi, 2016-05-09
On Monday 09 May 2016 13:39:50 Felipe Balbi wrote:
Arnd Bergmann [off-list ref] writes:
quoted
On Monday 09 May 2016 10:23:22 Benjamin Herrenschmidt wrote:
quoted
On Sun, 2016-05-08 at 13:44 +0200, Christian Lamparter wrote:
The patch that caused the problem had multiple issues:

- it broke big-endian ARM kernels: any machine that was working
  correctly with a little-endian kernel is no longer using byteswaps
  on big-endian kernels, which clearly breaks them.
- On PowerPC the same thing must be true: if it was working before,
  using big-endian kernels is now broken. Unlike ARM, 32-bit PowerPC
  usually uses big-endian kernels, so they are likely all broken.
- The barrier for dwc2_writel is on the wrong side of the __raw_writel(),
  so the MMIO no longer synchronizes with DMA operations.
- On architectures that require specific CPU instructions for MMIO
  access, using the __raw_ variant may turn this into a pointer
  dereference that does not have the same effect as the readl/writel.

I think we can simply make this set of accessors architecture-dependent
(MIPS vs. the rest of the world) to revert ARM and PowerPC back to
the working version.
and patch all drivers similarly? Shouldn't arch/mips itself deal with it
and hide it from drivers ?
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,
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.

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. 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.

	Arnd
Thread (32 messages) 32 messages, 6 authors, last reply 2016-05-19
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help