> http://marc.info/?l=linux-usb&m=137158978503741&w=2 > > There's an xHCI spec ambiguity: Does the last valid context entry refer > to the last valid endpoint context in the *input* device context or the > *output* device context? > > The code currently assumes it refers to the input device context, namely > the endpoints we're adding or changing. If hardware needs the last > valid endpoint context for the re-calculated *output* device context, > then yes, this needs to be changed. However, based on spec errata, I > believe that's not the intent of the spec authors: > > http://marc.info/?l=linux-kernel&m=137208958411696&w=2 Oh, okay, it didn't even occur to me to interpret it that way. It seems very odd since then Context Entries is essentially redundant with the information already provided by the Add Context flags. > What is the impact if we calculate the valid last valid endpoint context > for the input context? Do you have evidence of hardware misbehaving? > If so, which hardware? I haven't actually seen a problem from this, it just seemed like the right thing to do for me when looking at it. The only real error we had was when the command fails due to Context Entries being 0. However, the question remains: What is the right value for Context Entries when we have no Add Context flags, or only the SLOT_FLAG? It should be perfectly legal to just drop a bunch of endpoints without adding/changing anything else, such as when you switch a UVC interface back to alternate setting 0 (which has no endpoints). Then the Input Context really ends at the Slot Context (DCI = 0), but Context Entries = 0 is very clearly forbidden in the spec. I guess we could just force it to 1 there and it would probably work, but that would technically be incorrect since the EP0 context is not updated and not part of the Add Context flags. -- 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
