On 05/30/2014 12:49 PM, Xenia Ragiadakou wrote: > On 30/05/2014 04:13 πμ, Saran Neti wrote: >> Hi Xenia, >> >> Thanks for looking into this. >> >> On Thu, May 29, 2014 at 6:31 PM, Xenia Ragiadakou <burzalodowa@xxxxxxxxx> wrote: >>> I misunderstood the following description regarding the slot id field of >>> Command Completion Event TRB: >>> >>> "The Slot ID field shall be updated by the xHC to reflect the slot >>> associated with the >>> command that generated the event, with the following exceptions: >>> - The Slot ID shall be cleared to ‘0’ for No Op, Set Latency Tolerance >>> Value, Get Port >>> Bandwidth, and Force Event Commands. >>> - The Slot ID shall be set to the ID of the newly allocated Device Slot for >>> the Enable Slot >>> Command. >>> - The value of Slot ID shall be vendor defined when generated by a vendor >>> defined command. >>> This value is used as an index in the Device Context Base Address Array to >>> select the Device >>> Context of the source device. If this Event is due to a Host Controller >>> Command, then this field >>> shall be cleared to ‘0’." >>> >>> The xhci spec rev1.0, for the Stop Endpoint Command, the Set TR Dequeue >>> Pointer Command and the Reset Endpoint Command, states explicitely that the >>> Command Completion Event placed on the Event Ring by the xHC shall have >>> initialized the Slot ID field to the value of the command’s Slot ID. >>> However, regarding the Reset Device Command it states that this field should >>> be cleared to zero. So, it was my mistake and your hardware is compatible >>> with the spec. >>> >> >> While the spec appears to be unambiguous about Slot ID for >> Reset Device event TRB (always 0), in the case of >> Set TR Dequeue Pointer Command, Section 4.6.10 says (in xHCI rev 1.1 - >> is rev 1.0 similar?): >> >> "To issue a Set TR Dequeue Pointer Command system software shall >> perform the following operations: >> ... >> Write the Host Controller Doorbell with DB Target = Host Controller Command >> ... >> >> When a Set TR Dequeue Pointer Command is executed by the xHC it shall >> perform the following operations: >> ... >> Slot ID = The value of the command?s Slot ID. >> ..." >> >> So, when xHC writes a Set TR Dequeue Pointer Command Completion Event >> on the ring, there seem to be two different, possibly contradictory, >> ways to do it: >> 1. Following 4.6.10, "Slot ID = The value of the command?s Slot ID." >> 2. Following your quoted block of text from 6.4.2.2, "If this Event is >> due to a Host Controller Command, then this (Slot ID) field shall be >> cleared to 0" >> >> Both statements use 'shall', which according Word Usage is the new >> 'must'. Is there a Section-wise precedence order for cases like this? >> >> The other two commands - Stop Endpoint Command and Reset Endpoint >> Command are also subject to the same conundrum, if indeed there is >> one. >> >> If I'm mistaken, the email + patch I sent yesterday should be ignored: >> http://www.spinics.net/lists/linux-usb/msg108566.html >> > > Hi Saran, > > I think the same ambiguation in spec holds also for the cases of Disable Slot, > Address Device, Configure Endpoint and Evaluate Context Command Completion Event > TRBs that they were using already the completion event's Slot ID field, right? So, > based on which criteria in some cases completion event's slot id field can be used > and in others cannot? I don't know maybe Sarah or Mathias can clear that out. > > regards, > Xenia Hi Back from a public holiday and Checked xhci 1.0 and 1.1 specs As Saran pointed out, xhci specs sections 4.6.x clearly state what the SLOT ID field should be in the command completion events in most cases. One of the exceptions is Reset Device, it doesn't say anything about the value of the returned SLOT ID. So here the Reset Device SLOT ID returned is left unclear. The command completion event TRB description in section 6.4.2.2 gives some indication of what the SLOT ID field could be: "-The Slot ID field shall be updated by the xHC to reflect the slot associated with the command that generated the event, with the following exceptions: - The Slot ID shall be cleared to ‘0’ for No Op, Set Latency Tolerance Value, Get Port Bandwidth, and Force Event Commands. - The Slot ID shall be set to the ID of the newly allocated Device Slot for the Enable Slot Command. - The value of Slot ID shall be vendor defined when generated by a vendor defined command." As Reset Device is not listed in the exceptions it should "reflect the slot associated with the command that generated the event" This is the only place we get a hint about SLOT ID for Reset Device. I think the last part is not relevant in this case: "If this Event is due to a Host Controller Command, then this field shall be cleared to ‘0’." Is for xhci internal commands that also generate command completion events, but are not related to a command TRB put on a command ring. For example Stopping the command ring or aborting a command (section 4.6.1.1 and 4.6.1.2). These are triggered by writing to a xhci registers, but they still generate command completion events. (no command TRB is ever put on the command ring). The SLOT ID for reset device command completion TRB's isn't very well documented. If VIA chose to set it to zero we should use what works best, e.g. dig out the SLOT ID from the queued command TRB. This has been working previously. I'd like to use Saran's patch partly, I'd like to keep Xenia's WARN and compare SLOT ID's in the cases specs clearly specify event SLOT ID. In the Reset Device case use the command TRB SLOT ID. I can do this myself, but if you, Saran, feel you want to send a patch for it please let me know -Mathias -- 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
