Joel Stanley | b314cb5 | 2017-06-07 14:51:57 +0930 | [diff] [blame] | 1 | From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 |
| 2 | From: Jeremy Kerr <jk@ozlabs.org> |
| 3 | Date: Thu, 1 Dec 2016 18:15:59 +0800 |
| 4 | Subject: [PATCH 09/11] usb/xhci: allow xhci_check_bandwith in |
| 5 | XHCI_STATE_REMOVING |
| 6 | |
| 7 | Change 98d74f9ce (and backported as 0eb1e16bf9) introduced |
| 8 | XHCI_STATE_REMOVING, where PCI XHCI HCDs are flagged as removing dring |
| 9 | pci->remove. This included a check in xhci_check_bandwith to supress any |
| 10 | configuration changes while the hcd is in this state. |
| 11 | |
| 12 | However, it looks like some controllers hang during halt if we haven't |
| 13 | set configration 0 (via usb_hcd_alloc_bandwidth()). |
| 14 | |
| 15 | This change allows the configuration 0 update while removing. |
| 16 | |
| 17 | [This may be specific to our XHCI hacks for kexec...] |
| 18 | |
| 19 | From Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>: |
| 20 | |
| 21 | > What concerned me about 0004-xhci-do-not-halt-the-secondary-HCD.patch |
| 22 | > was that I'd still see eventual halt failures , though they seemed to |
| 23 | > occur on the shutdown hook, instead of the distro probe path. But since |
| 24 | > the probe goes ok, the bind continues and the device doesn't disappear. |
| 25 | > With JK's patch applied, I ran a bind-unbind stress test and couldn't |
| 26 | > reproduce the halt failure anymore. further probe and enumeration seems |
| 27 | > to work ok. |
| 28 | > |
| 29 | > I don't understand why the change fixes the hang but as JK said, it may |
| 30 | > be a particularity of this TI device not handling halts correctly . I |
| 31 | > don't think it will be accepted upstream as is, though, so we might want |
| 32 | > to make it a hardware quirk for this specific device if we confirm the |
| 33 | > TI device requires it for proper halting. |
| 34 | > |
| 35 | > Other than that, i think it's safe to make the change, and I don't think |
| 36 | > xhci spec forbids reconfiguration prior to halt. |
| 37 | > |
| 38 | > In short, this seems to work but I don't fully understand why. It |
| 39 | > doesn't seem harmful and if it fixes the issue, we can make it a quirk. |
| 40 | |
| 41 | Signed-off-by: Jeremy Kerr <jk@ozlabs.org> |
| 42 | Signed-off-by: Joel Stanley <joel@jms.id.au> |
| 43 | --- |
| 44 | drivers/usb/host/xhci.c | 3 +-- |
| 45 | 1 file changed, 1 insertion(+), 2 deletions(-) |
| 46 | |
| 47 | diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c |
| 48 | index 28fad2949308..c808e2e1f499 100644 |
| 49 | --- a/drivers/usb/host/xhci.c |
| 50 | +++ b/drivers/usb/host/xhci.c |
| 51 | @@ -2757,8 +2757,7 @@ int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev) |
| 52 | if (ret <= 0) |
| 53 | return ret; |
| 54 | xhci = hcd_to_xhci(hcd); |
| 55 | - if ((xhci->xhc_state & XHCI_STATE_DYING) || |
| 56 | - (xhci->xhc_state & XHCI_STATE_REMOVING)) |
| 57 | + if (xhci->xhc_state & XHCI_STATE_DYING) |
| 58 | return -ENODEV; |
| 59 | |
| 60 | xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev); |
| 61 | -- |
| 62 | 2.11.0 |
| 63 | |