On Wed, 20 Apr 2011, Jan Andersson wrote: > The two first HC capability registers (CAPLENGTH and HCIVERSION) > are defined as one 8-bit and one 16-bit register. Most HC > implementations have selected to treat these registers as part > of a 32-bit register, giving the same layout for both big and > small endian systems. > > This patch adds a new quirk, big_endian_capbase, to support > controllers with big endian register interfaces that treat > HCIVERSION and CAPLENGTH as individual registers. > > Signed-off-by: Jan Andersson <jan@xxxxxxxxxxx> > --- > This solution has previously been discussed on linux-usb [1] where > Alan Stern described the problem better: Except that I forgot that a byte has _two_ hex digits! > As an example for the sake of argument, let's suppose that CAPLENGTH is > 3 and HCIVERSION is 0x67. If the controller is in little-endian mode, These should be 0x03 and 0x0607. > this means that the memory-mapped registers will contain the following > bytes (starting from offset 0): 3 0 7 6. Any CPU, whether Make that 0x03 0x00 0x07 0x06. > little-endian or big-endian, using ehci_readl() would obtain 0x6703, Make that 0x06070003. > and the macros would then yield the correct values. > > Now suppose the controller is in big-endian mode. The memory-mapped > registers will contain the bytes: 3 0 6 7. Any CPU, whether Make that 0x03 0x00 0x06 0x07. > little-endian or big-endian, using ehci_readl() would obtain 0x3067, Make that 0x03000607. > which of course doesn't work with the HC_LENGTH and HC_VERSION macros Regardless... Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
