On 10/11/2013 09:26 PM, Sarah Sharp wrote:
On Fri, Oct 11, 2013 at 07:30:17PM +0300, Xenia Ragiadakou wrote:
[snip]
To test if a smaller value will cause a problem, I reset first
endpoint 4 and, then, endpoint 3 so that the Context Entries field
get updated with the value 3 while the actual last valid endpoint is
4.
Did you happen to see what the Context Entries field in the Output Slot
Context was after the command finished? I would expect it to remain at
4, even though the Context Entries field in the Input Slot Context would
have been 3.
No, it was changed to 3. When I say that the Context Entries field got
updated I am always referring to the Context Entries field of the Output
Slot Context.
Endpoint 4 is a BULK OUT endpoint so I checked if I could write to
the device. I didn't experience any issues when writing.
Then, I issued a Stop Endpoint command to EP 4 and although its
number is higher than the number kept in Context Entries field, the
Stop Endpoint command completed successfully.
Then, I issued a Set TR Dequeue pointer command to EP 4 and also
completed successfully.
At last, I issued a Disable Slot command to see if all the Endpoint
Contexts for the slot will be disabled and not only those in the
range of Context Entries and indeed all of them were disabled.
So, I guess that my changelog was unreasonably ominous and that the
patch can be dropped.
Ok, I'll drop it, and notify the testers they don't need the second
patch.
From the above it seems that xHC does not update with the vallue in
the Context Entries field of the Input Slot Context any internal
register used in determining currently valid endpoints.
The Output Slot Context Entries should still reflect which endpoints the
hardware thinks are currently valid.
No, the Output Slot Context Entries gets updated with the value of the
Input Slot Context Entries, irrespectively of whether the new value
reflects the true number of context entries.
That's the confusing part.
Sarah Sharp
The thing is that the value in the Output Slot Context Entries stops to
reflect the true last valid endpoint.
But xHC does not seem to care about. I don't know if the xhci driver
needs it to reflect the true last valid endpoint but that is another thing.
regards,
ksenia
--
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
