[PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues

[Jerome Forissier]

Hi Marek,

Sorry or digging up an old discussion.... I work for Linaro and one of the
tasks I am considering is helping out with the USB stack update/re-sync.
Not that I know much at all about USB :-\ but at least I will be able to
spend some cycles on that subject.

Please see below.

On 10/17/23 16:54, Marek Vasut wrote:
> On 10/17/23 16:16, Tom Rini wrote:
>> On Tue, Oct 17, 2023 at 03:48:37PM +0300, Eugen Hristev wrote:
>>> On 10/16/23 22:30, Tom Rini wrote:
>>>> On Mon, Oct 16, 2023 at 08:34:16AM +0200, Michal Simek wrote:
>>>>>
>>>>>
>>>>> On 10/13/23 17:15, Tom Rini wrote:
>>>>>> On Fri, Oct 13, 2023 at 11:11:04AM -0400, Da Xue wrote:
>>>>>>> On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut <marex at denx.de> wrote:
>>>>>>>>
>>>>>>>> On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote:
>>>>>>>>> The xhci host controller driver trying to queue the URB's and it is
>>>>>>>>> getting halted at the endpoint, thereby hitting the BUG_ON's.
>>>>>>>>> Mostly these kind of random issues are seen on faulty boards.
>>>>>>>>> Removing these BUG_ON's from the U-Boot xhci code, as in Linux kernel
>>>>>>>>> xhci code BUG_ON/BUG's are removed entirely.
>>>>>>>>> Please also note, that BUG_ON() is not recommended any more in the Linux
>>>>>>>>> kernel.
>>>>>>>>> Similar issue has been observed on TI AM437x board and they created a patch
>>>>>>>>> in Linux kernel as below
>>>>>>>>> https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-balbi@ti.com/
>>>>>>>>>
>>>>>>>>> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu at amd.com>
>>>>>>>>
>>>>>>>> I already explained to Xilinx how to sync the driver with Linux and why
>>>>>>>> this is needed to move forward, multiple times, and even provided a
>>>>>>>> script which does most of the work automatically, since it is basically
>>>>>>>> automated process. Xilinx did not even bother to test the script and
>>>>>>>> provide any feedback.
>>>>>>>>
>>>>>>>> Until that happens, this patch is rejected.

Would you mind telling me a bit more about the re-sync process and the script
you mentioned?

>>>>>>>
>>>>>>> This patch also causes all of the USB devices on certain platforms to
>>>>>>> not be detected:
>>>>>>>
>>>>>>> scanning bus usb at c9000000 for devices... Device not responding to set address.
>>>>>>>
>>>>>>>          USB device not accepting new address (error=80000000)
>>>>>>
>>>>>> Yes, we are stuck at the impasse where the custodian is asking for
>>>>>> someone to try and do the re-sync, and everyone else will assist with
>>>>>> testing on other platforms, but the re-sync hasn't happened.  Can we
>>>>>> please get someone from AMD to attempt the re-sync?
>>>>>
>>>>> I would like to say that we have someone to do it. But I simply don't have
>>>>> that person.
>>>>
>>>> That is the big problem we face, yes.  Eugen, I think you said you were
>>>> going to try and find time to do a re-sync, did you end up getting any?
>>>>
>>>
>>>
>>> Hi Tom,
>>>
>>> Unfortunately at the moment I am working on a different project, so I do not
>>> see any perspective to do this in the near future, although I would like to
>>> do it and to help.
>>> It may be the case that a company investing into an engineer to work on this
>>> would be the only way.

I might be that guy :)

>>>
>>> In any case, do you think Marek would accept doing this incrementally , e.g.
>>> now the driver is synced with 3.10, it would be easier to increment to 4.1
>>> as a first step ?
>>
>> Incremental updates feels like it might be less of a daunting path to
>> me, so I'd be agreeable.  Marek?
> 
> I am fine with that obviously, in fact, I am fine with anything which is not "pick a random patch from the middle of kernel git log, submit it, make the driver into a mess of partial patch backports".

Makes sense of course. What could be a first, simple step in the right
direction?

Regards,
-- 
Jerome