Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
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 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 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. This patch also causes all of the USB devices on certain platforms to not be detected: scanning bus usb@c900 for devices... Device not responding to set address. USB device not accepting new address (error=8000) 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. 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".
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
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 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 > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > This patch also causes all of the USB devices on certain platforms to > > > > > not be detected: > > > > > > > > > > scanning bus usb@c900 for devices... Device not responding to set > > > > > address. > > > > > > > > > > USB device not accepting new address (error=8000) > > > > > > > > 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. > > 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? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
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 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 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. This patch also causes all of the USB devices on certain platforms to not be detected: scanning bus usb@c900 for devices... Device not responding to set address. USB device not accepting new address (error=8000) 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. 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 ? Eugen
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
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 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 > > > > > > > > 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. > > > > > > This patch also causes all of the USB devices on certain platforms to > > > not be detected: > > > > > > scanning bus usb@c900 for devices... Device not responding to set > > > address. > > > > > >USB device not accepting new address (error=8000) > > > > 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? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
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 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 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. This patch also causes all of the USB devices on certain platforms to not be detected: scanning bus usb@c900 for devices... Device not responding to set address. USB device not accepting new address (error=8000) 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. Thanks, Michal
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
On Fri, Oct 13, 2023 at 11:11:04AM -0400, Da Xue wrote: > On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut 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 > > > > 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. > > This patch also causes all of the USB devices on certain platforms to > not be detected: > > scanning bus usb@c900 for devices... Device not responding to set address. > > USB device not accepting new address (error=8000) 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? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut 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 > > 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. This patch also causes all of the USB devices on certain platforms to not be detected: scanning bus usb@c900 for devices... Device not responding to set address. USB device not accepting new address (error=8000)
Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues
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 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.
