Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v4 1/1] usb: xhci: Add Clear_TT_Buffer
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     Jim Lin <jilin@nvidia.com>, gregkh@linuxfoundation.org,
        mathias.nyman@intel.com, hminas@synopsys.com,
        kai.heng.feng@canonical.com, drinkcat@chromium.org,
        prime.zeng@hisilicon.com, malat@debian.org, nsaenzjulienne@suse.de,
        jflat@chromium.org, linus.walleij@linaro.org, clabbe@baylibre.com,
        colin.king@canonical.com, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <Pine.LNX.4.44L0.1905071022140.1632-100000@iolanthe.rowland.org>
From:   Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <6164e645-dce7-27a8-70b0-5e37a540f288@linux.intel.com>
Date:   Wed, 8 May 2019 13:21:03 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.4.44L0.1905071022140.1632-100000@iolanthe.rowland.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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