Release 4.4.70-openpower1
Move to the latest stable release for the 4.4 branch. Importantly this
picks up 'scsi: lpfc: Add shutdown method for kexec'.
Signed-off-by: Joel Stanley <joel@jms.id.au>
diff --git a/openpower/linux/0009-usb-xhci-allow-xhci_check_bandwith-in-XHCI_STATE_REM.patch b/openpower/linux/0009-usb-xhci-allow-xhci_check_bandwith-in-XHCI_STATE_REM.patch
new file mode 100644
index 0000000..6fbd316
--- /dev/null
+++ b/openpower/linux/0009-usb-xhci-allow-xhci_check_bandwith-in-XHCI_STATE_REM.patch
@@ -0,0 +1,63 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Jeremy Kerr <jk@ozlabs.org>
+Date: Thu, 1 Dec 2016 18:15:59 +0800
+Subject: [PATCH 09/11] 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>
+---
+ drivers/usb/host/xhci.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
+index 28fad2949308..c808e2e1f499 100644
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -2757,8 +2757,7 @@ int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+ if (ret <= 0)
+ return ret;
+ xhci = hcd_to_xhci(hcd);
+- if ((xhci->xhc_state & XHCI_STATE_DYING) ||
+- (xhci->xhc_state & XHCI_STATE_REMOVING))
++ if (xhci->xhc_state & XHCI_STATE_DYING)
+ return -ENODEV;
+
+ xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev);
+--
+2.11.0
+