Alan Stern wrote:
All right, I think I understand the problem now.
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,
this means that the memory-mapped registers will contain the following
bytes (starting from offset 0): 3 0 7 6. Any CPU, whether
little-endian or big-endian, using ehci_readl() would obtain 0x6703,
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
little-endian or big-endian, using ehci_readl() would obtain 0x3067,
which of course doesn't work with the HC_LENGTH and HC_VERSION macros,
as you noted.
Yes, I believe that this describes the situation.
So what you need to do is redefine those macros:
#define HC_LENGTH(ehci, p) (0xff & ((p) >> \
(ehci_big_endian_mmio(ehci) ? 24 : 0)))
#define HC_VERSION(ehci, p) (0xffff & ((p) >> \
(ehci_big_endian_mmio(ehci) ? 0 : 16)))
Again, a comment would help explain the necessity for this.
Right, this should solve the problem for all my cases.
Of course, all the existing usages of the macros would then have to be
fixed up, but that shouldn't be too hard.
I am also worried that the addition of le32_to_cpu() could break the
existing drivers. If a driver works today on a _big endian_ cpu,
wouldn't the addition of le32_to_cpu() break it? I'm guessing that this
can be an issue for ehci-ppc-of? - But I may be wrong..
The solution above should work okay with any CPU. Whether it works
with other big-endian controllers is another matter -- if they
implement the CAPLENGTH and HCIVERSION registers properly (i.e., as
1-byte and 2-byte registers rather than as parts of a 4-byte register)
then it will. Still, you should check with the other maintainers.
And don't assume that the existing code necessarily is correct; it
might not be.
I will prepare a patch, test, try to get comments from the maintainers,
and reply to this thread after that. Thank you for your help.
Best regards,
Jan
--
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
