--- /dev/null
+From 99f2b130370b904ca5300079243fdbcafa2c708b Mon Sep 17 00:00:00 2001
+From: Peter Maydell <peter.maydell@linaro.org>
+Date: Thu, 22 Aug 2013 17:47:50 +0100
+Subject: ARM: PCI: versatile: Fix SMAP register offsets
+
+From: Peter Maydell <peter.maydell@linaro.org>
+
+commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream.
+
+The SMAP register offsets in the versatile PCI controller code were
+all off by four. (This didn't have any observable bad effects
+because on this board PHYS_OFFSET is zero, and (a) writing zero to
+the flags register at offset 0x10 has no effect and (b) the reset
+value of the SMAP register is zero anyway, so failing to write SMAP2
+didn't matter.)
+
+Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Kevin Hilman <khilman@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-versatile/pci.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/arm/mach-versatile/pci.c
++++ b/arch/arm/mach-versatile/pci.c
+@@ -42,9 +42,9 @@
+ #define PCI_IMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x0)
+ #define PCI_IMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x4)
+ #define PCI_IMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x8)
+-#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x10)
+-#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14)
+-#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18)
++#define PCI_SMAP0 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x14)
++#define PCI_SMAP1 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x18)
++#define PCI_SMAP2 __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0x1c)
+ #define PCI_SELFID __IO_ADDRESS(VERSATILE_PCI_CORE_BASE+0xc)
+
+ #define DEVICE_ID_OFFSET 0x00
--- /dev/null
+From 73e216a8a42c0ef3d08071705c946c38fdbe12b0 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@redhat.com>
+Date: Thu, 5 Sep 2013 08:38:10 -0400
+Subject: cifs: ensure that srv_mutex is held when dealing with ssocket pointer
+
+From: Jeff Layton <jlayton@redhat.com>
+
+commit 73e216a8a42c0ef3d08071705c946c38fdbe12b0 upstream.
+
+Oleksii reported that he had seen an oops similar to this:
+
+BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
+IP: [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
+PGD 0
+Oops: 0000 [#1] PREEMPT SMP
+Modules linked in: ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables carl9170 ath usb_storage f2fs nfnetlink_log nfnetlink md4 cifs dns_resolver hid_generic usbhid hid af_packet uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev rfcomm btusb bnep bluetooth qmi_wwan qcserial cdc_wdm usb_wwan usbnet usbserial mii snd_hda_codec_hdmi snd_hda_codec_realtek iwldvm mac80211 coretemp intel_powerclamp kvm_intel kvm iwlwifi snd_hda_intel cfg80211 snd_hda_codec xhci_hcd e1000e ehci_pci snd_hwdep sdhci_pci snd_pcm ehci_hcd microcode psmouse sdhci thinkpad_acpi mmc_core i2c_i801 pcspkr usbcore hwmon snd_timer snd_page_alloc snd ptp rfkill pps_core soundcore evdev usb_common vboxnetflt(O) vboxdrv(O)Oops#2 Part8
+ loop tun binfmt_misc fuse msr acpi_call(O) ipv6 autofs4
+CPU: 0 PID: 21612 Comm: kworker/0:1 Tainted: G W O 3.10.1SIGN #28
+Hardware name: LENOVO 2306CTO/2306CTO, BIOS G2ET92WW (2.52 ) 02/22/2013
+Workqueue: cifsiod cifs_echo_request [cifs]
+task: ffff8801e1f416f0 ti: ffff880148744000 task.ti: ffff880148744000
+RIP: 0010:[<ffffffff814dcc13>] [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
+RSP: 0000:ffff880148745b00 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: ffff880148745b78 RCX: 0000000000000048
+RDX: ffff880148745c90 RSI: ffff880181864a00 RDI: ffff880148745b78
+RBP: ffff880148745c48 R08: 0000000000000048 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000000 R12: ffff880181864a00
+R13: ffff880148745c90 R14: 0000000000000048 R15: 0000000000000048
+FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000088 CR3: 000000020c42c000 CR4: 00000000001407b0
+Oops#2 Part7
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
+Stack:
+ ffff880148745b30 ffffffff810c4af9 0000004848745b30 ffff880181864a00
+ ffffffff81ffbc40 0000000000000000 ffff880148745c90 ffffffff810a5aab
+ ffff880148745bc0 ffffffff81ffbc40 ffff880148745b60 ffffffff815a9fb8
+Call Trace:
+ [<ffffffff810c4af9>] ? finish_task_switch+0x49/0xe0
+ [<ffffffff810a5aab>] ? lock_timer_base.isra.36+0x2b/0x50
+ [<ffffffff815a9fb8>] ? _raw_spin_unlock_irqrestore+0x18/0x40
+ [<ffffffff810a673f>] ? try_to_del_timer_sync+0x4f/0x70
+ [<ffffffff815aa38f>] ? _raw_spin_unlock_bh+0x1f/0x30
+ [<ffffffff814dcc87>] kernel_sendmsg+0x37/0x50
+ [<ffffffffa081a0e0>] smb_send_kvec+0xd0/0x1d0 [cifs]
+ [<ffffffffa081a263>] smb_send_rqst+0x83/0x1f0 [cifs]
+ [<ffffffffa081ab6c>] cifs_call_async+0xec/0x1b0 [cifs]
+ [<ffffffffa08245e0>] ? free_rsp_buf+0x40/0x40 [cifs]
+Oops#2 Part6
+ [<ffffffffa082606e>] SMB2_echo+0x8e/0xb0 [cifs]
+ [<ffffffffa0808789>] cifs_echo_request+0x79/0xa0 [cifs]
+ [<ffffffff810b45b3>] process_one_work+0x173/0x4a0
+ [<ffffffff810b52a1>] worker_thread+0x121/0x3a0
+ [<ffffffff810b5180>] ? manage_workers.isra.27+0x2b0/0x2b0
+ [<ffffffff810bae00>] kthread+0xc0/0xd0
+ [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
+ [<ffffffff815b199c>] ret_from_fork+0x7c/0xb0
+ [<ffffffff810bad40>] ? kthread_create_on_node+0x120/0x120
+Code: 84 24 b8 00 00 00 4c 89 f1 4c 89 ea 4c 89 e6 48 89 df 4c 89 60 18 48 c7 40 28 00 00 00 00 4c 89 68 30 44 89 70 14 49 8b 44 24 28 <ff> 90 88 00 00 00 3d ef fd ff ff 74 10 48 8d 65 e0 5b 41 5c 41
+ RIP [<ffffffff814dcc13>] sock_sendmsg+0x93/0xd0
+ RSP <ffff880148745b00>
+CR2: 0000000000000088
+
+The client was in the middle of trying to send a frame when the
+server->ssocket pointer got zeroed out. In most places, that we access
+that pointer, the srv_mutex is held. There's only one spot that I see
+that the server->ssocket pointer gets set and the srv_mutex isn't held.
+This patch corrects that.
+
+The upstream bug report was here:
+
+ https://bugzilla.kernel.org/show_bug.cgi?id=60557
+
+Reported-by: Oleksii Shevchuk <alxchk@gmail.com>
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Steve French <smfrench@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/connect.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -362,6 +362,7 @@ cifs_reconnect(struct TCP_Server_Info *s
+ try_to_freeze();
+
+ /* we should try only the port we connected to before */
++ mutex_lock(&server->srv_mutex);
+ rc = generic_ip_connect(server);
+ if (rc) {
+ cFYI(1, "reconnect error %d", rc);
+@@ -373,6 +374,7 @@ cifs_reconnect(struct TCP_Server_Info *s
+ server->tcpStatus = CifsNeedNegotiate;
+ spin_unlock(&GlobalMid_Lock);
+ }
++ mutex_unlock(&server->srv_mutex);
+ } while (server->tcpStatus == CifsNeedReconnect);
+
+ return rc;
crypto-api-fix-race-condition-in-larval-lookup.patch
powerpc-handle-unaligned-ldbrx-stdbrx.patch
xen-gnt-prevent-adding-duplicate-gnt-callbacks.patch
+arm-pci-versatile-fix-smap-register-offsets.patch
+xhci-plat-don-t-enable-legacy-pci-interrupts.patch
+usb-xhci-disable-runtime-pm-suspend-for-quirky-controllers.patch
+cifs-ensure-that-srv_mutex-is-held-when-dealing-with-ssocket-pointer.patch
--- /dev/null
+From c8476fb855434c733099079063990e5bfa7ecad6 Mon Sep 17 00:00:00 2001
+From: Shawn Nematbakhsh <shawnn@chromium.org>
+Date: Mon, 19 Aug 2013 10:36:13 -0700
+Subject: usb: xhci: Disable runtime PM suspend for quirky controllers
+
+From: Shawn Nematbakhsh <shawnn@chromium.org>
+
+commit c8476fb855434c733099079063990e5bfa7ecad6 upstream.
+
+If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
+a reset will be performed upon runtime resume. Any previously suspended
+devices attached to the controller will be re-enumerated at this time.
+This will cause problems, for example, if an open system call on the
+device triggered the resume (the open call will fail).
+
+Note that this change is only relevant when persist_enabled is not set
+for USB devices.
+
+This patch should be backported to kernels as old as 3.0, that
+contain the commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 "xhci: Add
+reset on resume quirk for asrock p67 host".
+
+Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -3501,10 +3501,21 @@ void xhci_free_dev(struct usb_hcd *hcd,
+ {
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct xhci_virt_device *virt_dev;
++ struct device *dev = hcd->self.controller;
+ unsigned long flags;
+ u32 state;
+ int i, ret;
+
++#ifndef CONFIG_USB_DEFAULT_PERSIST
++ /*
++ * We called pm_runtime_get_noresume when the device was attached.
++ * Decrement the counter here to allow controller to runtime suspend
++ * if no devices remain.
++ */
++ if (xhci->quirks & XHCI_RESET_ON_RESUME)
++ pm_runtime_put_noidle(dev);
++#endif
++
+ ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
+ /* If the host is halted due to driver unload, we still need to free the
+ * device.
+@@ -3576,6 +3587,7 @@ static int xhci_reserve_host_control_ep_
+ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
+ {
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
++ struct device *dev = hcd->self.controller;
+ unsigned long flags;
+ int timeleft;
+ int ret;
+@@ -3628,6 +3640,16 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
+ goto disable_slot;
+ }
+ udev->slot_id = xhci->slot_id;
++
++#ifndef CONFIG_USB_DEFAULT_PERSIST
++ /*
++ * If resetting upon resume, we can't put the controller into runtime
++ * suspend if there is a device attached.
++ */
++ if (xhci->quirks & XHCI_RESET_ON_RESUME)
++ pm_runtime_get_noresume(dev);
++#endif
++
+ /* Is this a LS or FS device under a HS hub? */
+ /* Hub or peripherial? */
+ return 1;
--- /dev/null
+From 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 Mon Sep 17 00:00:00 2001
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Date: Thu, 8 Aug 2013 10:08:34 -0700
+Subject: xhci-plat: Don't enable legacy PCI interrupts.
+
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+
+commit 52fb61250a7a132b0cfb9f4a1060a1f3c49e5a25 upstream.
+
+The xHCI platform driver calls into usb_add_hcd to register the irq for
+its platform device. It does not want the xHCI generic driver to
+register an interrupt for it at all. The original code did that by
+setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
+enable MSI or MSI-X for a PCI host.
+
+Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
+the xHCI generic driver will attempt to register a legacy PCI interrupt
+for the xHCI platform device in xhci_try_enable_msi(). This will result
+in a bogus irq being registered, since the underlying device is a
+platform_device, not a pci_device, and thus the pci_device->irq pointer
+will be bogus.
+
+Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
+distinguish between a PCI device that can't handle MSI or MSI-X, and a
+platform device that should not have its interrupts touched at all.
+This quirk may be useful in the future, in case other corner cases like
+this arise.
+
+This patch should be backported to kernels as old as 3.9, that
+contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
+correctly enable interrupts".
+
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Reported-by: Yu Y Wang <yu.y.wang@intel.com>
+Tested-by: Yu Y Wang <yu.y.wang@intel.com>
+Reviewed-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-plat.c | 2 +-
+ drivers/usb/host/xhci.c | 7 ++++++-
+ drivers/usb/host/xhci.h | 1 +
+ 3 files changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-plat.c
++++ b/drivers/usb/host/xhci-plat.c
+@@ -24,7 +24,7 @@ static void xhci_plat_quirks(struct devi
+ * here that the generic code does not try to make a pci_dev from our
+ * dev struct in order to setup MSI
+ */
+- xhci->quirks |= XHCI_BROKEN_MSI;
++ xhci->quirks |= XHCI_PLAT;
+ }
+
+ /* called during probe() after chip reset completes */
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -342,9 +342,14 @@ static void xhci_msix_sync_irqs(struct x
+ static int xhci_try_enable_msi(struct usb_hcd *hcd)
+ {
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
++ struct pci_dev *pdev;
+ int ret;
+
++ /* The xhci platform device has set up IRQs through usb_add_hcd. */
++ if (xhci->quirks & XHCI_PLAT)
++ return 0;
++
++ pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
+ /*
+ * Some Fresco Logic host controllers advertise MSI, but fail to
+ * generate interrupts. Don't even try to enable MSI.
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1508,6 +1508,7 @@ struct xhci_hcd {
+ #define XHCI_SPURIOUS_REBOOT (1 << 13)
+ #define XHCI_COMP_MODE_QUIRK (1 << 14)
+ #define XHCI_AVOID_BEI (1 << 15)
++#define XHCI_PLAT (1 << 16)
+ unsigned int num_active_eps;
+ unsigned int limit_active_eps;
+ /* There are two roothubs to keep track of bus suspend info for */
projects / thirdparty / kernel / stable-queue.git / commitdiff
