--- /dev/null
+From 945b47441d83d2392ac9f984e0267ad521f24268 Mon Sep 17 00:00:00 2001
+From: Lior Amsalem <alior@marvell.com>
+Date: Tue, 30 Jun 2015 16:09:49 +0200
+Subject: ata: pmp: add quirk for Marvell 4140 SATA PMP
+
+From: Lior Amsalem <alior@marvell.com>
+
+commit 945b47441d83d2392ac9f984e0267ad521f24268 upstream.
+
+This commit adds the necessary quirk to make the Marvell 4140 SATA PMP
+work properly. This PMP doesn't like SRST on port number 4 (the host
+port) so this commit marks this port as not supporting SRST.
+
+Signed-off-by: Lior Amsalem <alior@marvell.com>
+Reviewed-by: Nadav Haklai <nadavh@marvell.com>
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-pmp.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/ata/libata-pmp.c
++++ b/drivers/ata/libata-pmp.c
+@@ -460,6 +460,13 @@ static void sata_pmp_quirks(struct ata_p
+ ATA_LFLAG_NO_SRST |
+ ATA_LFLAG_ASSUME_ATA;
+ }
++ } else if (vendor == 0x11ab && devid == 0x4140) {
++ /* Marvell 4140 quirks */
++ ata_for_each_link(link, ap, EDGE) {
++ /* port 4 is for SEMB device and it doesn't like SRST */
++ if (link->pmp == 4)
++ link->flags |= ATA_LFLAG_DISABLED;
++ }
+ }
+ }
+
--- /dev/null
+From 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Wed, 22 Jul 2015 18:05:53 -0400
+Subject: blkcg: fix gendisk reference leak in blkg_conf_prep()
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 5f6c2d2b7dbb541c1e922538c49fa04c494ae3d7 upstream.
+
+When a blkcg configuration is targeted to a partition rather than a
+whole device, blkg_conf_prep fails with -EINVAL; unfortunately, it
+forgets to put the gendisk ref in that case. Fix it.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-cgroup.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -703,8 +703,12 @@ int blkg_conf_prep(struct blkcg *blkcg,
+ return -EINVAL;
+
+ disk = get_gendisk(MKDEV(major, minor), &part);
+- if (!disk || part)
++ if (!disk)
+ return -EINVAL;
++ if (part) {
++ put_disk(disk);
++ return -EINVAL;
++ }
+
+ rcu_read_lock();
+ spin_lock_irq(disk->queue->queue_lock);
--- /dev/null
+From 968491709e5b1aaf429428814fff3d932fa90b60 Mon Sep 17 00:00:00 2001
+From: Bernhard Bender <bernhard.bender@bytecmed.com>
+Date: Thu, 23 Jul 2015 13:58:08 -0700
+Subject: Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen
+
+From: Bernhard Bender <bernhard.bender@bytecmed.com>
+
+commit 968491709e5b1aaf429428814fff3d932fa90b60 upstream.
+
+This patch fixes a problem in the usbtouchscreen driver for DMC TSC-30
+touch screen. Due to a missing delay between the RESET and SET_RATE
+commands, the touch screen may become unresponsive during system startup or
+driver loading.
+
+According to the DMC documentation, a delay is needed after the RESET
+command to allow the chip to complete its internal initialization. As this
+delay is not guaranteed, we had a system where the touch screen
+occasionally did not send any touch data. There was no other indication of
+the problem.
+
+The patch fixes the problem by adding a 150ms delay between the RESET and
+SET_RATE commands.
+
+Suggested-by: Jakob Mustafa <jakob.mustafa@bytecmed.com>
+Signed-off-by: Bernhard Bender <bernhard.bender@bytecmed.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/touchscreen/usbtouchscreen.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/input/touchscreen/usbtouchscreen.c
++++ b/drivers/input/touchscreen/usbtouchscreen.c
+@@ -625,6 +625,9 @@ static int dmc_tsc10_init(struct usbtouc
+ goto err_out;
+ }
+
++ /* TSC-25 data sheet specifies a delay after the RESET command */
++ msleep(150);
++
+ /* set coordinate output rate */
+ buf[0] = buf[1] = 0xFF;
+ ret = usb_control_msg(dev, usb_rcvctrlpipe (dev, 0),
--- /dev/null
+From 34cab6f42003cb06f48f86a86652984dec338ae9 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Fri, 24 Jul 2015 09:22:16 +1000
+Subject: md/raid1: fix test for 'was read error from last working device'.
+
+From: NeilBrown <neilb@suse.com>
+
+commit 34cab6f42003cb06f48f86a86652984dec338ae9 upstream.
+
+When we get a read error from the last working device, we don't
+try to repair it, and don't fail the device. We simple report a
+read error to the caller.
+
+However the current test for 'is this the last working device' is
+wrong.
+When there is only one fully working device, it assumes that a
+non-faulty device is that device. However a spare which is rebuilding
+would be non-faulty but so not the only working device.
+
+So change the test from "!Faulty" to "In_sync". If ->degraded says
+there is only one fully working device and this device is in_sync,
+this must be the one.
+
+This bug has existed since we allowed read_balance to read from
+a recovering spare in v3.0
+
+Reported-and-tested-by: Alexander Lyakas <alex.bolshoy@gmail.com>
+Fixes: 76073054c95b ("md/raid1: clean up read_balance.")
+Signed-off-by: NeilBrown <neilb@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -336,7 +336,7 @@ static void raid1_end_read_request(struc
+ spin_lock_irqsave(&conf->device_lock, flags);
+ if (r1_bio->mddev->degraded == conf->raid_disks ||
+ (r1_bio->mddev->degraded == conf->raid_disks-1 &&
+- !test_bit(Faulty, &conf->mirrors[mirror].rdev->flags)))
++ test_bit(In_sync, &conf->mirrors[mirror].rdev->flags)))
+ uptodate = 1;
+ spin_unlock_irqrestore(&conf->device_lock, flags);
+ }
mac80211-clear-subdir_stations-when-removing-debugfs.patch
mmc-sdhci-esdhc-make-8bit-bus-work.patch
mmc-sdhci-pxav3-fix-platform_data-is-not-initialized.patch
+md-raid1-fix-test-for-was-read-error-from-last-working-device.patch
+tile-use-free_bootmem_late-for-initrd.patch
+input-usbtouchscreen-avoid-unresponsive-tsc-30-touch-screen.patch
+blkcg-fix-gendisk-reference-leak-in-blkg_conf_prep.patch
+ata-pmp-add-quirk-for-marvell-4140-sata-pmp.patch
+usb-storage-ignore-zte-mf-823-card-reader-in-mode-0x1225.patch
+xhci-calculate-old-endpoints-correctly-on-device-reset.patch
+xhci-report-u3-when-link-is-in-resume-state.patch
+xhci-prevent-bus_suspend-if-ss-port-resuming-in-phase-1.patch
+xhci-do-not-report-plc-when-link-is-in-internal-resume-state.patch
+x86-efi-use-all-64-bit-of-efi_memmap-in-setup_e820.patch
--- /dev/null
+From 3f81d2447b37ac697b3c600039f2c6b628c06e21 Mon Sep 17 00:00:00 2001
+From: Chris Metcalf <cmetcalf@ezchip.com>
+Date: Thu, 23 Jul 2015 14:11:09 -0400
+Subject: tile: use free_bootmem_late() for initrd
+
+From: Chris Metcalf <cmetcalf@ezchip.com>
+
+commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream.
+
+We were previously using free_bootmem() and just getting lucky
+that nothing too bad happened.
+
+Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/tile/kernel/setup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/tile/kernel/setup.c
++++ b/arch/tile/kernel/setup.c
+@@ -1146,7 +1146,7 @@ static void __init load_hv_initrd(void)
+
+ void __init free_initrd_mem(unsigned long begin, unsigned long end)
+ {
+- free_bootmem(__pa(begin), end - begin);
++ free_bootmem_late(__pa(begin), end - begin);
+ }
+
+ static int __init setup_initrd(char *str)
--- /dev/null
+From 5fb2c782f451a4fb9c19c076e2c442839faf0f76 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Mon, 6 Jul 2015 13:12:32 +0200
+Subject: usb-storage: ignore ZTE MF 823 card reader in mode 0x1225
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit 5fb2c782f451a4fb9c19c076e2c442839faf0f76 upstream.
+
+This device automatically switches itself to another mode (0x1405)
+unless the specific access pattern of Windows is followed in its
+initial mode. That makes a dirty unmount of the internal storage
+devices inevitable if they are mounted. So the card reader of
+such a device should be ignored, lest an unclean removal become
+inevitable.
+
+This replaces an earlier patch that ignored all LUNs of this device.
+That patch was overly broad.
+
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Reviewed-by: Lars Melin <larsm17@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/storage/unusual_devs.h | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -2032,6 +2032,18 @@ UNUSUAL_DEV( 0x1908, 0x3335, 0x0200, 0x0
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_READ_DISC_INFO ),
+
++/* Reported by Oliver Neukum <oneukum@suse.com>
++ * This device morphes spontaneously into another device if the access
++ * pattern of Windows isn't followed. Thus writable media would be dirty
++ * if the initial instance is used. So the device is limited to its
++ * virtual CD.
++ * And yes, the concept that BCD goes up to 9 is not heeded */
++UNUSUAL_DEV( 0x19d2, 0x1225, 0x0000, 0xffff,
++ "ZTE,Incorporated",
++ "ZTE WCDMA Technologies MSM",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_SINGLE_LUN ),
++
+ /* Reported by Sven Geggus <sven-usbst@geggus.net>
+ * This encrypted pen drive returns bogus data for the initial READ(10).
+ */
--- /dev/null
+From 7cc03e48965453b5df1cce5062c826189b04b960 Mon Sep 17 00:00:00 2001
+From: Dmitry Skorodumov <sdmitry@parallels.com>
+Date: Tue, 28 Jul 2015 18:38:32 +0400
+Subject: x86/efi: Use all 64 bit of efi_memmap in setup_e820()
+
+From: Dmitry Skorodumov <sdmitry@parallels.com>
+
+commit 7cc03e48965453b5df1cce5062c826189b04b960 upstream.
+
+The efi_info structure stores low 32 bits of memory map
+in efi_memmap and high 32 bits in efi_memmap_hi.
+
+While constructing pointer in the setup_e820(), need
+to take into account all 64 bit of the pointer.
+
+It is because on 64bit machine the function
+efi_get_memory_map() may return full 64bit pointer and before
+the patch that pointer was truncated.
+
+The issue is triggered on Parallles virtual machine and
+fixed with this patch.
+
+Signed-off-by: Dmitry Skorodumov <sdmitry@parallels.com>
+Cc: Denis V. Lunev <den@openvz.org>
+Signed-off-by: Matt Fleming <matt.fleming@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/boot/compressed/eboot.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/x86/boot/compressed/eboot.c
++++ b/arch/x86/boot/compressed/eboot.c
+@@ -560,6 +560,10 @@ static efi_status_t setup_e820(struct bo
+ unsigned int e820_type = 0;
+ unsigned long m = efi->efi_memmap;
+
++#ifdef CONFIG_X86_64
++ m |= (u64)efi->efi_memmap_hi << 32;
++#endif
++
+ d = (efi_memory_desc_t *)(m + (i * efi->efi_memdesc_size));
+ switch (d->type) {
+ case EFI_RESERVED_TYPE:
--- /dev/null
+From 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 Mon Sep 17 00:00:00 2001
+From: Brian Campbell <bacam@z273.org.uk>
+Date: Tue, 21 Jul 2015 17:20:28 +0300
+Subject: xhci: Calculate old endpoints correctly on device reset
+
+From: Brian Campbell <bacam@z273.org.uk>
+
+commit 326124a027abc9a7f43f72dc94f6f0f7a55b02b3 upstream.
+
+When resetting a device the number of active TTs may need to be
+corrected by xhci_update_tt_active_eps, but the number of old active
+endpoints supplied to it was always zero, so the number of TTs and the
+bandwidth reserved for them was not updated, and could rise
+unnecessarily.
+
+This affected systems using Intel's Patherpoint chipset, which rely on
+software bandwidth checking. For example, a Lenovo X230 would lose the
+ability to use ports on the docking station after enough suspend/resume
+cycles because the bandwidth calculated would rise with every cycle when
+a suitable device is attached.
+
+The correct number of active endpoints is calculated in the same way as
+in xhci_reserve_bandwidth.
+
+Signed-off-by: Brian Campbell <bacam@z273.org.uk>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -3424,6 +3424,9 @@ int xhci_discover_or_reset_device(struct
+ return -EINVAL;
+ }
+
++ if (virt_dev->tt_info)
++ old_active_eps = virt_dev->tt_info->active_eps;
++
+ if (virt_dev->udev != udev) {
+ /* If the virt_dev and the udev does not match, this virt_dev
+ * may belong to another udev.
--- /dev/null
+From aca3a0489ac019b58cf32794d5362bb284cb9b94 Mon Sep 17 00:00:00 2001
+From: Zhuang Jin Can <jin.can.zhuang@intel.com>
+Date: Tue, 21 Jul 2015 17:20:31 +0300
+Subject: xhci: do not report PLC when link is in internal resume state
+
+From: Zhuang Jin Can <jin.can.zhuang@intel.com>
+
+commit aca3a0489ac019b58cf32794d5362bb284cb9b94 upstream.
+
+Port link change with port in resume state should not be
+reported to usbcore, as this is an internal state to be
+handled by xhci driver. Reporting PLC to usbcore may
+cause usbcore clearing PLC first and port change event irq
+won't be generated.
+
+Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -587,7 +587,14 @@ static u32 xhci_get_port_status(struct u
+ status |= USB_PORT_STAT_C_RESET << 16;
+ /* USB3.0 only */
+ if (hcd->speed == HCD_USB3) {
+- if ((raw_port_status & PORT_PLC))
++ /* Port link change with port in resume state should not be
++ * reported to usbcore, as this is an internal state to be
++ * handled by xhci driver. Reporting PLC to usbcore may
++ * cause usbcore clearing PLC first and port change event
++ * irq won't be generated.
++ */
++ if ((raw_port_status & PORT_PLC) &&
++ (raw_port_status & PORT_PLS_MASK) != XDEV_RESUME)
+ status |= USB_PORT_STAT_C_LINK_STATE << 16;
+ if ((raw_port_status & PORT_WRC))
+ status |= USB_PORT_STAT_C_BH_RESET << 16;
--- /dev/null
+From fac4271d1126c45ceaceb7f4a336317b771eb121 Mon Sep 17 00:00:00 2001
+From: Zhuang Jin Can <jin.can.zhuang@intel.com>
+Date: Tue, 21 Jul 2015 17:20:30 +0300
+Subject: xhci: prevent bus_suspend if SS port resuming in phase 1
+
+From: Zhuang Jin Can <jin.can.zhuang@intel.com>
+
+commit fac4271d1126c45ceaceb7f4a336317b771eb121 upstream.
+
+When the link is just waken, it's in Resume state, and driver sets PLS to
+U0. This refers to Phase 1. Phase 2 refers to when the link has completed
+the transition from Resume state to U0.
+
+With the fix of xhci: report U3 when link is in resume state, it also
+exposes an issue that usb3 roothub and controller can suspend right
+after phase 1, and this causes a hard hang in controller.
+
+To fix the issue, we need to prevent usb3 bus suspend if any port is
+resuming in phase 1.
+
+[merge separate USB2 and USB3 port resume checking to one -Mathias]
+Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 6 +++---
+ drivers/usb/host/xhci-ring.c | 3 +++
+ drivers/usb/host/xhci.h | 1 +
+ 3 files changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -1117,10 +1117,10 @@ int xhci_bus_suspend(struct usb_hcd *hcd
+ spin_lock_irqsave(&xhci->lock, flags);
+
+ if (hcd->self.root_hub->do_remote_wakeup) {
+- if (bus_state->resuming_ports) {
++ if (bus_state->resuming_ports || /* USB2 */
++ bus_state->port_remote_wakeup) { /* USB3 */
+ spin_unlock_irqrestore(&xhci->lock, flags);
+- xhci_dbg(xhci, "suspend failed because "
+- "a port is resuming\n");
++ xhci_dbg(xhci, "suspend failed because a port is resuming\n");
+ return -EBUSY;
+ }
+ }
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1740,6 +1740,9 @@ static void handle_port_status(struct xh
+ usb_hcd_resume_root_hub(hcd);
+ }
+
++ if (hcd->speed == HCD_USB3 && (temp & PORT_PLS_MASK) == XDEV_INACTIVE)
++ bus_state->port_remote_wakeup &= ~(1 << faked_port_index);
++
+ if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_RESUME) {
+ xhci_dbg(xhci, "port resume event for port %d\n", port_id);
+
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -285,6 +285,7 @@ struct xhci_op_regs {
+ #define XDEV_U0 (0x0 << 5)
+ #define XDEV_U2 (0x2 << 5)
+ #define XDEV_U3 (0x3 << 5)
++#define XDEV_INACTIVE (0x6 << 5)
+ #define XDEV_RESUME (0xf << 5)
+ /* true: port has power (see HCC_PPC) */
+ #define PORT_POWER (1 << 9)
--- /dev/null
+From 243292a2ad3dc365849b820a64868927168894ac Mon Sep 17 00:00:00 2001
+From: Zhuang Jin Can <jin.can.zhuang@intel.com>
+Date: Tue, 21 Jul 2015 17:20:29 +0300
+Subject: xhci: report U3 when link is in resume state
+
+From: Zhuang Jin Can <jin.can.zhuang@intel.com>
+
+commit 243292a2ad3dc365849b820a64868927168894ac upstream.
+
+xhci_hub_report_usb3_link_state() returns pls as U0 when the link
+is in resume state, and this causes usb core to think the link is in
+U0 while actually it's in resume state. When usb core transfers
+control request on the link, it fails with TRB error as the link
+is not ready for transfer.
+
+To fix the issue, report U3 when the link is in resume state, thus
+usb core knows the link it's not ready for transfer.
+
+Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-hub.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-hub.c
++++ b/drivers/usb/host/xhci-hub.c
+@@ -480,10 +480,13 @@ static void xhci_hub_report_usb3_link_st
+ u32 pls = status_reg & PORT_PLS_MASK;
+
+ /* resume state is a xHCI internal state.
+- * Do not report it to usb core.
++ * Do not report it to usb core, instead, pretend to be U3,
++ * thus usb core knows it's not ready for transfer
+ */
+- if (pls == XDEV_RESUME)
++ if (pls == XDEV_RESUME) {
++ *status |= USB_SS_PORT_LS_U3;
+ return;
++ }
+
+ /* When the CAS bit is set then warm reset
+ * should be performed on port
projects / thirdparty / kernel / stable-queue.git / commitdiff
