On 7.5.2019 17.29, Alan Stern wrote:
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.
Agree, adding address to struct usb_device sounds better.
-Mathias
