Hi Julie,
Julie Zhu wrote:
I do not agree with you that what Linux is doing is a violation to the
Then you seem to be the only one.
EHCI spec. It is taken as granted that a definition in big endian swaps
the bytes versus the definition in little endian. Since all values are
accessed in 32-bits, definitions have to be taken into the context that
everything is viewed in 32-bit word.
The EHCI specification states that the operational registers are DWord
aligned registers that can only be accessed with DWord (32-bit)
accesses. This is stated in section 2.3. The capability registers
defined in section 2.2 do not have this restriction and are not all
32-bit registers.
Just to clarify; I do not see it as a big deal that Linux does not take
the above into account when performing a 32-bit access to read CAPLENGTH
and HCI VERSION. The person that added support for big endian MMIO
probably wanted a particular piece of hardware supported that had the
capability registers arranged in that way.
That you implemented your host controller first according to the EHCI
Spec and then changed in order to be, well, Linux compliant is also fine
with me. I did not mean my remark as offensive as I see it as obvious
that the EHCI spec does not define CAPLENGTH to be at address base+0x03,
therefore I thought that you were aware that you did not implement your
controller according to spec.
So, if put the EHCI spec of CAPLEN
is the first byte in the first word, then what Linux defines and what we
have done are exactly what the EHCI spec says.
The EHCI spec defines the CAPLENGTH register to be at offset Base + 00h
(not as the first byte in the first word, that would be open to
interpretation). Your CAPLENGTH register is not at this address. If you
perform a byte access to the offset where CAPLENGTH is specified to be
located, you will not get the value of CAPLENGTH. It is as simple as
that (and yes, it is entirely likely that software would read that
register using a byte access, I have ported software that did exactly
this - and it is allowed by the spec).
Same goes to the bit
definitions. We swap all the bits in the word, 31th becomes first, and
first becomes 31th, which is different from the spec.
Surely you do not perform a bit-wise swap? In that case you have a very
special interface. The bytes may be swapped, not the individual bits.
That you may call the bit with value 2^x something else than x is a
documentation issue, if an issue at all. What matters is the value you
get when you perform an access that is as wide as the register (in the
case of CAPLENGTH, a byte access).
Do you think that
is a violation to the spec too? And how will it work if we keep all the
bit positions as the same as the EHCI spec?
I do not see this as a problem. Some literature name say that the MSb of
a 32-bit word should be named bit 0, others say that it should be named 31.
If you want to continue to discuss this perhaps it would be better to do
so off list (note that my first e-mail to you was off list and you
replied here), in any case this will be my last post to the list on this
thread since I do not see the benefit of discussing it further. It will
just be noise.
The specification is freely available and everyone who wishes to do so
can make up their own mind on where an 8-bit register that starts at
"base + 00h" should be placed. I got the information I asked for (which
was if I could change the HC_LENGTH and HC_VERSION macros without
breaking other drivers, and I can't). Now I hope that I eventually can
submit a patch so that there can be support for both types of hardware.
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
