Thread (28 messages) 28 messages, 6 authors, 2016-05-19

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

From: Felipe Balbi <hidden>
Date: 2016-05-09 10:42:05
Also in: linuxppc-dev, lkml

Hi,

Arnd Bergmann [off-list ref] writes:
On Monday 09 May 2016 10:23:22 Benjamin Herrenschmidt wrote:
quoted
On Sun, 2016-05-08 at 13:44 +0200, Christian Lamparter wrote:
quoted
On Sunday, May 08, 2016 08:40:55 PM Benjamin Herrenschmidt wrote:
quoted
On Sun, 2016-05-08 at 00:54 +0200, Christian Lamparter via Linuxppc-dev 
wrote:
quoted
I've been looking in getting the MyBook Live Duo's USB OTG port
to function. The SoC is a APM82181. Which has a PowerPC 464 core
and related to the supported canyonlands architecture in
arch/powerpc/.

Currently in -next the dwc2 module doesn't load: 
Smells like the APM implementation is little endian. You might need to
use a flag to indicate what endian to use instead and set it
appropriately based on some DT properties.
I tried. As per common-properties[0], I added little-endian; but it has no
effect. I looked in dwc2_driver_probe and found no way of specifying the
endian of the device. It all comes down to the dwc2_readl & dwc2_writel
accessors. These - sadly - have been hardwired to use __raw_readl and
__raw_writel. So, it's always "native-endian". While common-properties
says little-endian should be preferred.
Right, I meant, you should produce a patch adding a runtime test inside
those functions based on a device-tree property, a bit like we do for
some of the HCDs like OHCI, EHCI etc...
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 ?

-- 
balbi

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help