usb/xhci: allow xhci_check_bandwith in XHCI_STATE_REMOVING

Change 98d74f9ce (and backported as 0eb1e16bf9) introduced
XHCI_STATE_REMOVING, where PCI XHCI HCDs are flagged as removing dring
pci->remove. This included a check in xhci_check_bandwith to supress any
configuration changes while the hcd is in this state.

However, it looks like some controllers hang during halt if we haven't
set configration 0 (via usb_hcd_alloc_bandwidth()).

This change allows the configuration 0 update while removing.

[This may be specific to our XHCI hacks for kexec...]

From Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>:

 > What concerned me about 0004-xhci-do-not-halt-the-secondary-HCD.patch
 > was that I'd still see eventual halt failures , though they seemed to
 > occur on the shutdown hook, instead of the distro probe path. But since
 > the probe goes ok, the bind continues and the device doesn't disappear.
 > With JK's patch applied, I ran a bind-unbind stress test and couldn't
 > reproduce the halt failure anymore. further probe and enumeration seems
 > to work ok.
 >
 > I don't understand why the change fixes the hang but as JK said, it may
 > be a particularity of this TI device not handling halts correctly . I
 > don't think it will be accepted upstream as is, though, so we might want
 > to make it a hardware quirk for this specific device if we confirm the
 > TI device requires it for proper halting.
 >
 > Other than that, i think it's safe to make the change, and I don't think
 > xhci spec forbids reconfiguration prior to halt.
 >
 > In short, this seems to work but I don't fully understand why. It
 > doesn't seem harmful and if it fixes the issue, we can make it a quirk.

Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>

0 files changed, 0 insertions, 0 deletions