On Fri, May 30, 2014 at 9:26 AM, Mathias Nyman <mathias.nyman@xxxxxxxxx> wrote: > 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). That makes more sense. It'd be nicer if it were explicit. > 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. For Reset Device in Section 4.6.1, it says: "Insert a Command Completion Event on the Event Ring of Interrupter 0 and initialize the following fields: ... Clear all other fields of the event TRB to ‘0’." Can "all other fields" be interpreted to include Slot ID? > 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 Thanks for asking, but since the patch is trivial, it'll be easier/faster if you write/backport it. -- Saran -- 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
