On Tue, 7 May 2019, Mathias Nyman wrote: > On 6.5.2019 17.57, Alan Stern wrote: > > On Mon, 6 May 2019, Jim Lin wrote: > > > >> USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt > >> processing for full-/low-speed endpoints connected via a TT, the host > >> software must use the Clear_TT_Buffer request to the TT to ensure > >> that the buffer is not in the busy state". > >> > >> In our case, a full-speed speaker (ConferenceCam) is behind a high- > >> speed hub (ConferenceCam Connect), sometimes once we get STALL on a > >> request we may continue to get STALL with the folllowing requests, > >> like Set_Interface. > >> > >> Here we add Clear_TT_Buffer for the following Set_Interface requests > >> to get ACK successfully. > >> > >> Originally usb_hub_clear_tt_buffer uses urb->dev->devnum as device > >> address while sending Clear_TT_Buffer command, but this doesn't work > >> for XHCI. > > > > Why doesn't it work for xHCI? Clear-TT-Buffer is part of the USB 2.0 > > spec; it should work exactly the same for xHCI as for a USB-2.0 host > > controller. > > > > Alan Stern > > > > For other host controllers udev->devnum is the same as the address of the > usb device, chosen and set by usb core. > > With xHC the controller hardware assigns the address, and won't be the same as > devnum. > > The Clear-TT-Buffer request sent to the hub includes the address of the LS/FS > child device in wValue field. usb_hub_clear_tt_buffer() uses udev->devnum to set the > address wValue. This won't work for devices connected to xHC I see. Thanks for the explanation; it makes sense now. The patch description should explain this too. Wouldn't it be better to add a field containing the device address to struct usb_device? And also export it, either in sysfs or debugfs? It seems like the kind of thing that might be important for debugging. If we did this then the usb_hub_clear_tt_buffer API wouldn't need to be changed. Alan Stern
