Hi, Arnd Bergmann <arnd@xxxxxxxx> writes: > On Monday 09 May 2016 10:23:22 Benjamin Herrenschmidt wrote: >> On Sun, 2016-05-08 at 13:44 +0200, Christian Lamparter wrote: >> > On Sunday, May 08, 2016 08:40:55 PM Benjamin Herrenschmidt wrote: >> > > >> > > On Sun, 2016-05-08 at 00:54 +0200, Christian Lamparter via Linuxppc-dev >> > > wrote: >> > > > >> > > > 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
Attachment:
signature.asc
Description: PGP signature
