Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 21.12.2016 08:57, Lu Baolu wrote: Hi Mathias, I have some comments for the implementation of xhci_handle_command_timeout() as well. On 12/20/2016 11:13 PM, Mathias Nyman wrote: On 20.12.2016 09:30, Baolin Wang wrote: ... Alright, I gathered all current work related to xhci races

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 21.12.2016 08:17, Lu Baolu wrote: Hi Mathias, I have some comments for the implementation of xhci_abort_cmd_ring() below. On 12/20/2016 11:13 PM, Mathias Nyman wrote: On 20.12.2016 09:30, Baolin Wang wrote: ... Alright, I gathered all current work related to xhci races and timeouts

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 21.12.2016 08:17, Lu Baolu wrote: Hi Mathias, I have some comments for the implementation of xhci_abort_cmd_ring() below. On 12/20/2016 11:13 PM, Mathias Nyman wrote: On 20.12.2016 09:30, Baolin Wang wrote: ... Alright, I gathered all current work related to xhci races and timeouts

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 20.12.2016 09:30, Baolin Wang wrote: ... Alright, I gathered all current work related to xhci races and timeouts and put them into a branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git timeout_race_fixes Its based on 4.9 It includes a few other patches just to avoid

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 20.12.2016 09:30, Baolin Wang wrote: ... Alright, I gathered all current work related to xhci races and timeouts and put them into a branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git timeout_race_fixes Its based on 4.9 It includes a few other patches just to avoid

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 19.12.2016 13:34, Baolin Wang wrote: Hi Mathias, On 19 December 2016 at 18:33, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: On 13.12.2016 05:21, Baolin Wang wrote: Hi Mathias, On 12 December 2016 at 23:52, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: On 05.1

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 19.12.2016 13:34, Baolin Wang wrote: Hi Mathias, On 19 December 2016 at 18:33, Mathias Nyman wrote: On 13.12.2016 05:21, Baolin Wang wrote: Hi Mathias, On 12 December 2016 at 23:52, Mathias Nyman wrote: On 05.12.2016 09:51, Baolin Wang wrote: If a command event is found

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 13.12.2016 05:21, Baolin Wang wrote: Hi Mathias, On 12 December 2016 at 23:52, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: On 05.12.2016 09:51, Baolin Wang wrote: If a command event is found on the event ring during an interrupt, we need to stop the command timer with del

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 13.12.2016 05:21, Baolin Wang wrote: Hi Mathias, On 12 December 2016 at 23:52, Mathias Nyman wrote: On 05.12.2016 09:51, Baolin Wang wrote: If a command event is found on the event ring during an interrupt, we need to stop the command timer with del_timer(). Since del_timer() can fail

Re: xhci_reset_endpoint() doesn't reset endpoint

On 14.12.2016 12:58, Michal Necasek wrote: prior to the endpoint reset. SetFeature(CLEAR_HALT) resets the toggle on the device, but not on the host. But we know for a fact that the device sends a packet (with data toggle 0) which the host USB stack never sees, and a data toggle mismatch explains

Re: xhci_reset_endpoint() doesn't reset endpoint

On 14.12.2016 12:58, Michal Necasek wrote: prior to the endpoint reset. SetFeature(CLEAR_HALT) resets the toggle on the device, but not on the host. But we know for a fact that the device sends a packet (with data toggle 0) which the host USB stack never sees, and a data toggle mismatch explains

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 05.12.2016 09:51, Baolin Wang wrote: If a command event is found on the event ring during an interrupt, we need to stop the command timer with del_timer(). Since del_timer() can fail if the timer is running and waiting on the xHCI lock, then it maybe get the wrong timeout command in

Re: [PATCH 2/2] usb: host: xhci: Handle the right timeout command

On 05.12.2016 09:51, Baolin Wang wrote: If a command event is found on the event ring during an interrupt, we need to stop the command timer with del_timer(). Since del_timer() can fail if the timer is running and waiting on the xHCI lock, then it maybe get the wrong timeout command in

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

On 12.12.2016 06:00, Thang Q. Nguyen wrote: On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: From: Thang Nguyen As per USB 2.0 link power management addendum ECN, table 1-2, page 4, device

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

On 12.12.2016 06:00, Thang Q. Nguyen wrote: On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring wrote: On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote: From: Thang Nguyen As per USB 2.0 link power management addendum ECN, table 1-2, page 4, device or host initiated via resume

Re: Should xhci_irq() call usb_hc_died()?

On 12.12.2016 10:43, Felipe Balbi wrote: Hi, Bjorn Helgaas writes: Hi Mathias, ehci_irq(), ohci_irq(), fotg210_irq(), and oxu210_hcd_irq() contain code equivalent to this: status = ehci_readl(...); if (status == ~(u32) 0) { ... usb_hc_died(hcd); ...

Re: Should xhci_irq() call usb_hc_died()?

On 12.12.2016 10:43, Felipe Balbi wrote: Hi, Bjorn Helgaas writes: Hi Mathias, ehci_irq(), ohci_irq(), fotg210_irq(), and oxu210_hcd_irq() contain code equivalent to this: status = ehci_readl(...); if (status == ~(u32) 0) { ... usb_hc_died(hcd); ... return

Re: [PATCH 1/2] usb: host: xhci: Fix possible wild pointer when handling abort command

On 05.12.2016 09:51, Baolin Wang wrote: When current command was supposed to be aborted, host will free the command in handle_cmd_completion() function. But it might be still referenced by xhci->current_cmd, which need to set NULL. Signed-off-by: Baolin Wang --- This

Re: [PATCH 1/2] usb: host: xhci: Fix possible wild pointer when handling abort command

On 05.12.2016 09:51, Baolin Wang wrote: When current command was supposed to be aborted, host will free the command in handle_cmd_completion() function. But it might be still referenced by xhci->current_cmd, which need to set NULL. Signed-off-by: Baolin Wang --- This patch is based on Lu

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

On 02.12.2016 04:29, Lu Baolu wrote: handle_cmd_completion() frees a command structure which might be still referenced by xhci->current_cmd. This might cause problem when xhci->current_cmd is accessed after that. A real-life case could be like this. The host takes a very long time to respond to

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

On 02.12.2016 04:29, Lu Baolu wrote: handle_cmd_completion() frees a command structure which might be still referenced by xhci->current_cmd. This might cause problem when xhci->current_cmd is accessed after that. A real-life case could be like this. The host takes a very long time to respond to

Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command

On 01.12.2016 06:54, Baolin Wang wrote: On 30 November 2016 at 22:09, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: On 30.11.2016 11:02, Baolin Wang wrote: If the hardware never responds to the stop endpoint command, the URBs will never be completed, and we might hang the USB sub

Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command

On 01.12.2016 06:54, Baolin Wang wrote: On 30 November 2016 at 22:09, Mathias Nyman wrote: On 30.11.2016 11:02, Baolin Wang wrote: If the hardware never responds to the stop endpoint command, the URBs will never be completed, and we might hang the USB subsystem. The original watchdog timer

Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command

On 30.11.2016 11:02, Baolin Wang wrote: If the hardware never responds to the stop endpoint command, the URBs will never be completed, and we might hang the USB subsystem. The original watchdog timer is used to watch if one stop endpoint command is timeout, if timeout, then the watchdog timer

Re: [RFC] usb: host: xhci: Remove the watchdog timer and use command timer to watch stop endpoint command

On 30.11.2016 11:02, Baolin Wang wrote: If the hardware never responds to the stop endpoint command, the URBs will never be completed, and we might hang the USB subsystem. The original watchdog timer is used to watch if one stop endpoint command is timeout, if timeout, then the watchdog timer

Re: [PATCH 1/1] usb: return error code when platform_get_irq fails

On 30.11.2016 15:41, Matthias Brugger wrote: On 29/11/16 13:57, Pan Bian wrote: In function xhci_mtk_probe(), variable ret takes the return value. Its value should be negative on failures. However, when the call to function platform_get_irq() fails, it does not set the error code, and 0 will

Re: [PATCH 1/1] usb: return error code when platform_get_irq fails

On 30.11.2016 15:41, Matthias Brugger wrote: On 29/11/16 13:57, Pan Bian wrote: In function xhci_mtk_probe(), variable ret takes the return value. Its value should be negative on failures. However, when the call to function platform_get_irq() fails, it does not set the error code, and 0 will

Re: [PATCH v2] usb: xhci: Remove unuseful 'return' and 'break' statement

On 28.11.2016 09:41, Baolin Wang wrote: On 28 November 2016 at 15:21, Greg KH wrote: On Mon, Nov 28, 2016 at 02:29:25PM +0800, Baolin Wang wrote: Hi Mathias, On 24 November 2016 at 19:16, Baolin Wang wrote: Since these 'return' statements

Re: [PATCH v2] usb: xhci: Remove unuseful 'return' and 'break' statement

On 28.11.2016 09:41, Baolin Wang wrote: On 28 November 2016 at 15:21, Greg KH wrote: On Mon, Nov 28, 2016 at 02:29:25PM +0800, Baolin Wang wrote: Hi Mathias, On 24 November 2016 at 19:16, Baolin Wang wrote: Since these 'return' statements are not generally useful in void function, remove

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

On 21.11.2016 09:57, Rafał Miłecki wrote: Hi Mathias, On 17 October 2016 at 22:30, Rafał Miłecki wrote: From: Rafał Miłecki Broadcom's Northstar XHCI controllers seem to need a special start procedure to work correctly. There isn't any official

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

On 21.11.2016 09:57, Rafał Miłecki wrote: Hi Mathias, On 17 October 2016 at 22:30, Rafał Miłecki wrote: From: Rafał Miłecki Broadcom's Northstar XHCI controllers seem to need a special start procedure to work correctly. There isn't any official documentation of this, the problem is that

Re: [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device

On 15.11.2016 22:36, Guenter Roeck wrote: The following use-after-free reports were seen on resume with a specific USB hub. BUG: KASAN: use-after-free in xhci_free_virt_device+0x8c/0x21c at addr ffc0cc1a2eb0 BUG: KASAN: use-after-free in xhci_update_tt_active_eps+0x9c/0xdc

Re: [RFC PATCH] xhci: Fix memory use after free in xhci_free_virt_device

On 15.11.2016 22:36, Guenter Roeck wrote: The following use-after-free reports were seen on resume with a specific USB hub. BUG: KASAN: use-after-free in xhci_free_virt_device+0x8c/0x21c at addr ffc0cc1a2eb0 BUG: KASAN: use-after-free in xhci_update_tt_active_eps+0x9c/0xdc

Re: [PATCH] usb: host: xhci: Remove unused 'addr_64' variable in xhci_hcd structure

On 15.11.2016 10:34, Baolin Wang wrote: Since the 'addr_64' variable as legacy is unused now, then remove it from xhci_hcd structure. Signed-off-by: Baolin Wang --- Thanks, I'll add it to the queue -Mathias

Re: [PATCH] usb: host: xhci: Remove unused 'addr_64' variable in xhci_hcd structure

On 15.11.2016 10:34, Baolin Wang wrote: Since the 'addr_64' variable as legacy is unused now, then remove it from xhci_hcd structure. Signed-off-by: Baolin Wang --- Thanks, I'll add it to the queue -Mathias

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On 10.11.2016 13:22, Oliver Neukum wrote: On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: Kai-Heng Feng writes: On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: Oliver Neukum writes: On Tue, 2016-11-08 at 13:44 -0500,

Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On 10.11.2016 13:22, Oliver Neukum wrote: On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: Kai-Heng Feng writes: On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: Oliver Neukum writes: On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: These problems could very well be caused by

Re: [PATCH 1/1] usb: xhci: remove the use of xhci->addr_dev

On 02.11.2016 04:30, Lu Baolu wrote: xhci->addr_dev is used for the completion of both address device and enable slot commands. It's shared by enumerations of all USB devices connected to an xhci host. Hence, it's just a source for possible races. Since we've introduced command structure and the

Re: [PATCH 1/1] usb: xhci: remove the use of xhci->addr_dev

On 02.11.2016 04:30, Lu Baolu wrote: xhci->addr_dev is used for the completion of both address device and enable slot commands. It's shared by enumerations of all USB devices connected to an xhci host. Hence, it's just a source for possible races. Since we've introduced command structure and the

Re: [PATCH 1/1] usb: xhci: cleanup cmd_completion in xhci_virt_device

On 03.11.2016 12:22, Sergei Shtylyov wrote: On 11/3/2016 9:48 AM, Lu Baolu wrote: cmd_completion in struct xhci_virt_device is legacy. With command strutcture and command queue introduced in xhci, cmd_completion is Structure. I'll fix that while applying the patch, no need to resend

Re: [PATCH 1/1] usb: xhci: cleanup cmd_completion in xhci_virt_device

On 03.11.2016 12:22, Sergei Shtylyov wrote: On 11/3/2016 9:48 AM, Lu Baolu wrote: cmd_completion in struct xhci_virt_device is legacy. With command strutcture and command queue introduced in xhci, cmd_completion is Structure. I'll fix that while applying the patch, no need to resend

Re: [PATCH 1/1] usb: xhci: cleanup cmd_completion in xhci_virt_device

On 03.11.2016 08:48, Lu Baolu wrote: cmd_completion in struct xhci_virt_device is legacy. With command strutcture and command queue introduced in xhci, cmd_completion is not used any more. This patch removes it. Signed-off-by: Lu Baolu ---

Re: [PATCH 1/1] usb: xhci: cleanup cmd_completion in xhci_virt_device

On 03.11.2016 08:48, Lu Baolu wrote: cmd_completion in struct xhci_virt_device is legacy. With command strutcture and command queue introduced in xhci, cmd_completion is not used any more. This patch removes it. Signed-off-by: Lu Baolu --- drivers/usb/host/xhci-mem.c | 1 -

Re: [PATCH v2] usb: xhci: Don't drive port 2.0 reset while resuming

On 25.10.2016 13:45, Sriram Dash wrote: For the USB3.0 controller, USB 2.0 reset not driven while port is in Resume state. So, do not program the USB 2.0 reset (PORTSC[PR]=1) while in Resume state. Signed-off-by: Rajat Srivastava Signed-off-by: Sriram Dash

Re: [PATCH v2] usb: xhci: Don't drive port 2.0 reset while resuming

On 25.10.2016 13:45, Sriram Dash wrote: For the USB3.0 controller, USB 2.0 reset not driven while port is in Resume state. So, do not program the USB 2.0 reset (PORTSC[PR]=1) while in Resume state. Signed-off-by: Rajat Srivastava Signed-off-by: Sriram Dash Signed-off-by: Rajesh Bhagat ---

Re: [PATCH v2 RESEND] drivers/usb: Skip auto handoff for TI and RENESAS usb controllers

On 24.10.2016 17:52, Babu Moger wrote: On 10/24/2016 5:54 AM, Yoshihiro Shimoda wrote: Hi, From: Mathias Nyman Sent: Monday, October 24, 2016 6:58 PM On 22.10.2016 01:25, Babu Moger wrote: Never seen XHCI auto handoff working on TI and RENESAS cards. Eventually, we force handoff. This code

Re: [PATCH v2 RESEND] drivers/usb: Skip auto handoff for TI and RENESAS usb controllers

On 24.10.2016 17:52, Babu Moger wrote: On 10/24/2016 5:54 AM, Yoshihiro Shimoda wrote: Hi, From: Mathias Nyman Sent: Monday, October 24, 2016 6:58 PM On 22.10.2016 01:25, Babu Moger wrote: Never seen XHCI auto handoff working on TI and RENESAS cards. Eventually, we force handoff. This code

Re: [PATCH v2 RESEND] drivers/usb: Skip auto handoff for TI and RENESAS usb controllers

On 22.10.2016 01:25, Babu Moger wrote: Never seen XHCI auto handoff working on TI and RENESAS cards. Eventually, we force handoff. This code forces the handoff unconditionally. It saves 5 seconds boot time for each card. Signed-off-by: Babu Moger Do the Renesas and TI

Re: [PATCH v2 RESEND] drivers/usb: Skip auto handoff for TI and RENESAS usb controllers

On 22.10.2016 01:25, Babu Moger wrote: Never seen XHCI auto handoff working on TI and RENESAS cards. Eventually, we force handoff. This code forces the handoff unconditionally. It saves 5 seconds boot time for each card. Signed-off-by: Babu Moger Do the Renesas and TI controllers still

Re: [PATCH v2 1/1] usb: xhci: clean up error_bitmask usage

On 21.10.2016 06:14, Lu Baolu wrote: In xhci_handle_event(), when errors are detected, driver always sets a bit in error_bitmask (one member of the xhci private driver data). That means users have to retrieve and decode the value of error_bitmask in xhci private driver data if they want to know

Re: [PATCH v2 1/1] usb: xhci: clean up error_bitmask usage

On 21.10.2016 06:14, Lu Baolu wrote: In xhci_handle_event(), when errors are detected, driver always sets a bit in error_bitmask (one member of the xhci private driver data). That means users have to retrieve and decode the value of error_bitmask in xhci private driver data if they want to know

Re: [PATCH 1/1] usb: xhci: clean up error_bitmask usage

Hi On 19.10.2016 03:53, Lu Baolu wrote: In xhci_handle_event(), when errors are detected, driver always sets a bit in error_bitmask (one member of the xhci private driver data). That means users have to retrieve and decode the value of error_bitmask in xhci private driver data if they want to

Re: [PATCH 1/1] usb: xhci: clean up error_bitmask usage

Hi On 19.10.2016 03:53, Lu Baolu wrote: In xhci_handle_event(), when errors are detected, driver always sets a bit in error_bitmask (one member of the xhci private driver data). That means users have to retrieve and decode the value of error_bitmask in xhci private driver data if they want to

Re: [PATCH] usb: xhci: mark xhci_unmap_td_bounce_buffer() static

On 23.09.2016 16:46, Baoyou Xie wrote: We get 1 warning when building kernel with W=1: drivers/usb/host/xhci-ring.c:608:6: warning: no previous prototype for 'xhci_unmap_td_bounce_buffer' [-Wmissing-prototypes] In fact, this function is only used in the file in which it is declared and don't

Re: [PATCH] usb: xhci: mark xhci_unmap_td_bounce_buffer() static

On 23.09.2016 16:46, Baoyou Xie wrote: We get 1 warning when building kernel with W=1: drivers/usb/host/xhci-ring.c:608:6: warning: no previous prototype for 'xhci_unmap_td_bounce_buffer' [-Wmissing-prototypes] In fact, this function is only used in the file in which it is declared and don't

Re: [RFC PATCH] xhci: do not halt the secondary HCD

advice on an acceptable way to upstream the fix, so that the xhci device survives kexec. Any reason you didn't cc: Mathias? Fat fingers - I missed him when grabbing names from get_maintainers. Thanks for adding him in. On Mon, Sep 19, 2016 at 5:11 PM, Mathias Nyman <mathias.ny...@linux.intel.c

Re: [RFC PATCH] xhci: do not halt the secondary HCD

the fix, so that the xhci device survives kexec. Any reason you didn't cc: Mathias? Fat fingers - I missed him when grabbing names from get_maintainers. Thanks for adding him in. On Mon, Sep 19, 2016 at 5:11 PM, Mathias Nyman wrote: What kernel version is this? This patch is against 4.4.21

Re: [RFC PATCH] xhci: do not halt the secondary HCD

On 19.09.2016 09:35, Joel Stanley wrote: We can't halt the secondary HCD, because it's also the primary HCD, which will cause problems if we have devices attached to the primary HCD, like a keyboard. We've been carrying this in our Linux-as-a-bootloader environment for a little while now. The

Re: [RFC PATCH] xhci: do not halt the secondary HCD

On 19.09.2016 09:35, Joel Stanley wrote: We can't halt the secondary HCD, because it's also the primary HCD, which will cause problems if we have devices attached to the primary HCD, like a keyboard. We've been carrying this in our Linux-as-a-bootloader environment for a little while now. The

Re: [PATCH 1/1] usb: xhci: fix return value of xhci_setup_device()

On 07.09.2016 10:54, Lu Baolu wrote: Hi Mathias, On 09/07/2016 02:51 PM, Mathias Nyman wrote: On 07.09.2016 09:22, Lu Baolu wrote: From: "Lu, Baolu" <baolu...@linux.intel.com> xhci_setup_device() should return failure with correct error number when xhci host has died, r

Re: [PATCH 1/1] usb: xhci: fix return value of xhci_setup_device()

On 07.09.2016 10:54, Lu Baolu wrote: Hi Mathias, On 09/07/2016 02:51 PM, Mathias Nyman wrote: On 07.09.2016 09:22, Lu Baolu wrote: From: "Lu, Baolu" xhci_setup_device() should return failure with correct error number when xhci host has died, removed or halted. Thanks, will add

Re: [PATCH 1/1] usb: xhci: fix return value of xhci_setup_device()

On 07.09.2016 09:22, Lu Baolu wrote: From: "Lu, Baolu" xhci_setup_device() should return failure with correct error number when xhci host has died, removed or halted. Thanks, will add. Might go to 4.9 as 4.8-rc5 is already out -Mathias

Re: [PATCH 1/1] usb: xhci: fix return value of xhci_setup_device()

On 07.09.2016 09:22, Lu Baolu wrote: From: "Lu, Baolu" xhci_setup_device() should return failure with correct error number when xhci host has died, removed or halted. Thanks, will add. Might go to 4.9 as 4.8-rc5 is already out -Mathias

Re: [PATCH] usb: xhci-plat: Add generic PHY support

On 29.08.2016 10:26, Srinath Mannam wrote: Hi Mathias Nyman, Could you please provide your inputs on this? If you find it in good condition, please consider it for the next release. I'm not that involved in the usb phy or generic phy, but to me it looks like we should let usb core handle

Re: [PATCH] usb: xhci-plat: Add generic PHY support

On 29.08.2016 10:26, Srinath Mannam wrote: Hi Mathias Nyman, Could you please provide your inputs on this? If you find it in good condition, please consider it for the next release. I'm not that involved in the usb phy or generic phy, but to me it looks like we should let usb core handle

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

On 29.08.2016 10:28, Felipe Balbi wrote: Hi, Michael Niewöhner writes: [1.] One line summary of the problem: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 [2.] Full description of the problem/report: No usb 3.0 devices are being detected when attached while

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

On 29.08.2016 10:28, Felipe Balbi wrote: Hi, Michael Niewöhner writes: [1.] One line summary of the problem: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 [2.] Full description of the problem/report: No usb 3.0 devices are being detected when attached while USB 2.0 devices work on

Re: change in xhci result in soft lockup

On 14.08.2016 01:13, Kui Zhang wrote: Hello, System still hangs with 4.8.0-rc1+. There are new info in the logs. Does Alban Browaeys Patch xhci: really enqueue zero length TRBs help? It solves an ADB triggered issue in xhci in that same bad patch.

Re: change in xhci result in soft lockup

On 14.08.2016 01:13, Kui Zhang wrote: Hello, System still hangs with 4.8.0-rc1+. There are new info in the logs. Does Alban Browaeys Patch xhci: really enqueue zero length TRBs help? It solves an ADB triggered issue in xhci in that same bad patch.

Re: kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

On 04.07.2016 18:21, Lukas Wunner wrote: On Mon, Jul 04, 2016 at 06:04:42PM +0300, Mathias Nyman wrote: On 04.07.2016 17:25, Rafael J. Wysocki wrote: On Mon, Jul 4, 2016 at 4:26 PM, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: AceLan Kao can get his DELL XPS 13 laptop t

Re: kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

On 04.07.2016 18:21, Lukas Wunner wrote: On Mon, Jul 04, 2016 at 06:04:42PM +0300, Mathias Nyman wrote: On 04.07.2016 17:25, Rafael J. Wysocki wrote: On Mon, Jul 4, 2016 at 4:26 PM, Mathias Nyman wrote: AceLan Kao can get his DELL XPS 13 laptop to hang by plugging/un-plugging a USB 3.1 key

Re: kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

On 04.07.2016 17:25, Rafael J. Wysocki wrote: On Mon, Jul 4, 2016 at 4:26 PM, Mathias Nyman <mathias.ny...@linux.intel.com> wrote: Hi AceLan Kao can get his DELL XPS 13 laptop to hang by plugging/un-plugging a USB 3.1 key via thunderbolt port. Allocating memory fails after this,

Re: kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

On 04.07.2016 17:25, Rafael J. Wysocki wrote: On Mon, Jul 4, 2016 at 4:26 PM, Mathias Nyman wrote: Hi AceLan Kao can get his DELL XPS 13 laptop to hang by plugging/un-plugging a USB 3.1 key via thunderbolt port. Allocating memory fails after this, always pointing to NULL pointer or page

kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

Hi AceLan Kao can get his DELL XPS 13 laptop to hang by plugging/un-plugging a USB 3.1 key via thunderbolt port. Allocating memory fails after this, always pointing to NULL pointer or page request failing in get_freepointer() called by kmalloc/kmem_cache_alloc. Unplugging a usb type-c device

kmem_cache_alloc fail with unable to handle paging request after pci hotplug remove.

Hi AceLan Kao can get his DELL XPS 13 laptop to hang by plugging/un-plugging a USB 3.1 key via thunderbolt port. Allocating memory fails after this, always pointing to NULL pointer or page request failing in get_freepointer() called by kmalloc/kmem_cache_alloc. Unplugging a usb type-c device

Re: [PATCH] xhci: free the correct ring

_giveback_urb_in_irq(xhci, cur_td, 0); Thanks, Acked-by: Mathias Nyman <mathias.ny...@linux.intel.com> In most cases each endpoint has only one ring and one list of canceled TDs, so each TD on a cancelled_td_list is for the same ring. But with streams in use that might no longer be the

Re: [PATCH] xhci: free the correct ring

xhci, cur_td, 0); Thanks, Acked-by: Mathias Nyman In most cases each endpoint has only one ring and one list of canceled TDs, so each TD on a cancelled_td_list is for the same ring. But with streams in use that might no longer be the case. This does ensure that the streams work properl

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

On 28.04.2016 15:21, Felipe Balbi wrote: Hi, dmesg from PC host side (after adding your change without my patch): [17907.984647] usb 6-2: new SuperSpeed USB device number 54 using xhci_hcd [17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1 interface 1 altsetting 0 ep 2:

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

On 28.04.2016 15:21, Felipe Balbi wrote: Hi, dmesg from PC host side (after adding your change without my patch): [17907.984647] usb 6-2: new SuperSpeed USB device number 54 using xhci_hcd [17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1 interface 1 altsetting 0 ep 2:

Re: [PATCH v3] usb: core: hub: hub_port_init lock controller instead of bus

hub_set_address xhci_address_device xhci_setup_device Mathias Nyman explains the current behaviour violates the XHCI spec: hub_port_reset() will end up moving the corresponding xhci device slot to default state. As hub_port_reset() is called several times in hub_port_init

Re: [PATCH v3] usb: core: hub: hub_port_init lock controller instead of bus

hub_set_address xhci_address_device xhci_setup_device Mathias Nyman explains the current behaviour violates the XHCI spec: hub_port_reset() will end up moving the corresponding xhci device slot to default state. As hub_port_reset() is called several times in hub_port_init

Re: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value

On 11.04.2016 18:44, Peter Griffin wrote: Hi Mathias, On Fri, 25 Mar 2016, Peter Griffin wrote: Otherwise generic-xhci and xhci-platform which have no data get wrongly detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is(). This fixes a regression in v4.5 for STiH407 family SoC's

Re: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value

On 11.04.2016 18:44, Peter Griffin wrote: Hi Mathias, On Fri, 25 Mar 2016, Peter Griffin wrote: Otherwise generic-xhci and xhci-platform which have no data get wrongly detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is(). This fixes a regression in v4.5 for STiH407 family SoC's

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

On 07.04.2016 14:05, Thierry Reding wrote: On Thu, Apr 07, 2016 at 02:03:45PM +0300, Mathias Nyman wrote: On 04.03.2016 18:19, Thierry Reding wrote: From: Thierry Reding <tred...@nvidia.com> Add support for the on-chip XUSB controller present on Tegra SoCs. This controller, when

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

On 07.04.2016 14:05, Thierry Reding wrote: On Thu, Apr 07, 2016 at 02:03:45PM +0300, Mathias Nyman wrote: On 04.03.2016 18:19, Thierry Reding wrote: From: Thierry Reding Add support for the on-chip XUSB controller present on Tegra SoCs. This controller, when loaded with external firmware

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

ta <aj...@nvidia.com> Bharath Yadav <bya...@nvidia.com> Andrew Bresticker <abres...@chromium.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Mathias Nyman <mathias.ny...@intel.com> Signed-off-by: Thierry Reding <tred...@nvidia.com> ---

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

Andrew Bresticker Cc: Greg Kroah-Hartman Cc: Mathias Nyman Signed-off-by: Thierry Reding --- ... +static int tegra_xusb_remove(struct platform_device *pdev) +{ + struct tegra_xusb *tegra = platform_get_drvdata(pdev); > + struct usb_hcd *hcd = tegra->hcd; + struct xh

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

On 05.04.2016 16:35, Greg Kroah-Hartman wrote: On Tue, Apr 05, 2016 at 03:17:51PM +0200, Thierry Reding wrote: Hi Mathias, Greg, Due to the various dependencies within the series, I'd prefer this to go via the Tegra tree. Would you be okay with providing your Acked-by? That's all up to

Re: [PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

On 05.04.2016 16:35, Greg Kroah-Hartman wrote: On Tue, Apr 05, 2016 at 03:17:51PM +0200, Thierry Reding wrote: Hi Mathias, Greg, Due to the various dependencies within the series, I'd prefer this to go via the Tegra tree. Would you be okay with providing your Acked-by? That's all up to

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 01.04.2016 06:55, Rajesh Bhagat wrote: Please share your opinion on other changes for patch submission as well as resume time. I think more effort should be put into investigating why this happens in the first place. What is the root cause? why doesn't xhci start properly after

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 01.04.2016 06:55, Rajesh Bhagat wrote: Please share your opinion on other changes for patch submission as well as resume time. I think more effort should be put into investigating why this happens in the first place. What is the root cause? why doesn't xhci start properly after

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 31.03.2016 06:51, Rajesh Bhagat wrote: Hello Mathias, Thanks a lot for your support. Attached patch is working and allows the completion handler to be called. And resume operation completes and shell comes back (but with lot of errors). Now, some other points which needs our attention

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 31.03.2016 06:51, Rajesh Bhagat wrote: Hello Mathias, Thanks a lot for your support. Attached patch is working and allows the completion handler to be called. And resume operation completes and shell comes back (but with lot of errors). Now, some other points which needs our attention

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 28.03.2016 09:13, Rajesh Bhagat wrote: -Original Message- From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com] Sent: Wednesday, March 23, 2016 7:52 PM To: Rajesh Bhagat <rajesh.bha...@nxp.com> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linu

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 28.03.2016 09:13, Rajesh Bhagat wrote: -Original Message- From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com] Sent: Wednesday, March 23, 2016 7:52 PM To: Rajesh Bhagat Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org; Sriram Dash

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 23.03.2016 05:53, Rajesh Bhagat wrote: IMO, The assumption that "xhci_abort_cmd_ring would always generate an event and handle_cmd_completion would be called" will not be always be true if HW is in bad state. Please share your opinion. writing the CA (command abort) bit in CRCR

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 23.03.2016 05:53, Rajesh Bhagat wrote: IMO, The assumption that "xhci_abort_cmd_ring would always generate an event and handle_cmd_completion would be called" will not be always be true if HW is in bad state. Please share your opinion. writing the CA (command abort) bit in CRCR

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 22.03.2016 07:19, Rajesh Bhagat wrote: -Original Message- From: Mathias Nyman [mailto:mathias.ny...@intel.com] Sent: Monday, March 21, 2016 2:46 PM To: Rajesh Bhagat <rajesh.bha...@nxp.com>; Mathias Nyman <mathias.ny...@linux.intel.com>; linux-...@vger.kernel.org

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 22.03.2016 07:19, Rajesh Bhagat wrote: -Original Message- From: Mathias Nyman [mailto:mathias.ny...@intel.com] Sent: Monday, March 21, 2016 2:46 PM To: Rajesh Bhagat ; Mathias Nyman ; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org Cc: gre...@linuxfoundation.org; Sriram

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

On 21.03.2016 06:18, Rajesh Bhagat wrote: Hi I think clearing the whole command ring is a bit too much in this case. It may cause issues for all attached devices when one command times out. Hi Mathias, I understand your point, But I want to understand how would completion handler be

<    1   2   3   4   5   6   7   8   9   10   >