[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1463091454.3237.19.camel@kernel.crashing.org>
Date: Fri, 13 May 2016 08:17:34 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Christian Lamparter <chunkeey@...glemail.com>,
Arnd Bergmann <arnd@...db.de>
Cc: Felipe Balbi <felipe.balbi@...ux.intel.com>,
linux-mips@...ux-mips.org, johnyoun@...opsys.com,
gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, a.seppala@...il.com,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since
4.3.0-rc4
On Thu, 2016-05-12 at 11:58 +0200, Christian Lamparter wrote:
>
> > http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/2012-lpc-ref-big-little-endian-herrenschmidt.odp
> >
> > but there are at least two more twists that you completely missed here:
> >
> > - Some architectures (e.g. ARMv5 "BE32" mode in IXP4xx, surely some others)
> > do not implement big-endian mode by wiring up the data lines between the
> > bus and the CPU differently between big- and little-endian mode like
> > powerpc and armv7 "BE8" do, but instead they swizzle the *address* lines
> > on 8-bit and 16-bit addresses. The effect of that is that normal RAM
> > accesses work as expected both ways, and devices that are accessed using
> > 32-bit MMIO ops never need any byteswap (you actually get "native
> > endian") while MMIO with 8 and 16 bit width does something completely
> > unexpected and touches the wrong register. Having an explicit byteswap
> > on the PCI host bridge gets you the expected addresses again for 8-bit
> > cycles but it also means that readl()/writel() again need to swap the
> > data.
Right. Old PowerPC did that too and it's completely stupid. Thankfully
most vendors grew a clue since then and this practice has slowly fallen
into oblivion.
> > - Some other architectures (e.g. Broadcom MIPS) apparently are even fancier
> > and use a strapping pin on the SoC flips the endianess of the CPU core
> > at the same time as all the peripheral MMIO registers, with the intention
> > of never requiring any byte swaps. I believe they are implemented careful
> > enough to actually get this right, but it confuses the heck out of
> > Linux drivers that don't expect this.
Right. Drivers like that will need an explicit test in the accessors.
Cheers,
Ben.
Powered by blists - more mailing lists