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 <ma...@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-ba...@ti.com/ >>>>>>>>> >>>>>>>>> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbar...@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@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
