--- /dev/null
+From d19f503e22316a84c39bc19445e0e4fdd49b3532 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hp.com>
+Date: Wed, 10 Jul 2013 10:47:13 -0600
+Subject: ACPI / memhotplug: Fix a stale pointer in error path
+
+From: Toshi Kani <toshi.kani@hp.com>
+
+commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.
+
+device->driver_data needs to be cleared when releasing its data,
+mem_device, in an error path of acpi_memory_device_add().
+
+The function evaluates the _CRS of memory device objects, and fails
+when it gets an unexpected resource or cannot allocate memory. A
+kernel crash or data corruption may occur when the kernel accesses
+the stale pointer.
+
+Signed-off-by: Toshi Kani <toshi.kani@hp.com>
+Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/acpi_memhotplug.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/acpi/acpi_memhotplug.c
++++ b/drivers/acpi/acpi_memhotplug.c
+@@ -421,6 +421,7 @@ static int acpi_memory_device_add(struct
+ /* Get the range from the _CRS */
+ result = acpi_memory_get_device_resources(mem_device);
+ if (result) {
++ device->driver_data = NULL;
+ kfree(mem_device);
+ return result;
+ }
--- /dev/null
+From eac27f04a71e1f39f196f7e520d16dcefc955d77 Mon Sep 17 00:00:00 2001
+From: Youquan Song <youquan.song@intel.com>
+Date: Thu, 11 Jul 2013 21:15:57 -0400
+Subject: ata: Fix DVD not dectected at some platform with Wellsburg PCH
+
+From: Youquan Song <youquan.song@intel.com>
+
+commit eac27f04a71e1f39f196f7e520d16dcefc955d77 upstream.
+
+There is a patch b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD
+ not dectected at some Haswell platforms" to fix an issue of DVD not
+recognized on Haswell Desktop platform with Lynx Point.
+Recently, it is also found the same issue at some platformas with Wellsburg PCH.
+
+So deliver a similar patch to fix it by disables 32bit PIO in IDE mode.
+
+Signed-off-by: Youquan Song <youquan.song@intel.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/ata_piix.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/ata/ata_piix.c
++++ b/drivers/ata/ata_piix.c
+@@ -344,7 +344,7 @@ static const struct pci_device_id piix_p
+ /* SATA Controller IDE (Wellsburg) */
+ { 0x8086, 0x8d00, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Wellsburg) */
+- { 0x8086, 0x8d08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
++ { 0x8086, 0x8d08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
+ /* SATA Controller IDE (Wellsburg) */
+ { 0x8086, 0x8d60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
+ /* SATA Controller IDE (Wellsburg) */
--- /dev/null
+From fec386ac1428f9c0e672df952cbca5cebd4e4e2f Mon Sep 17 00:00:00 2001
+From: Josef Bacik <jbacik@fusionio.com>
+Date: Mon, 15 Jul 2013 12:41:42 -0400
+Subject: Btrfs: fix lock leak when resuming snapshot deletion
+
+From: Josef Bacik <jbacik@fusionio.com>
+
+commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f upstream.
+
+We aren't setting path->locks[level] when we resume a snapshot deletion which
+means we won't unlock the buffer when we free the path. This causes deadlocks
+if we happen to re-allocate the block before we've evicted the extent buffer
+from cache. Thanks,
+
+Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
+Signed-off-by: Josef Bacik <jbacik@fusionio.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent-tree.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -6903,6 +6903,7 @@ int btrfs_drop_snapshot(struct btrfs_roo
+ while (1) {
+ btrfs_tree_lock(path->nodes[level]);
+ btrfs_set_lock_blocking(path->nodes[level]);
++ path->locks[level] = BTRFS_WRITE_LOCK_BLOCKING;
+
+ ret = btrfs_lookup_extent_info(trans, root,
+ path->nodes[level]->start,
+@@ -6919,6 +6920,7 @@ int btrfs_drop_snapshot(struct btrfs_roo
+ break;
+
+ btrfs_tree_unlock(path->nodes[level]);
++ path->locks[level] = 0;
+ WARN_ON(wc->refs[level] != 1);
+ level--;
+ }
--- /dev/null
+From d29a9f629e009c9b90e5859bce581070fd6247fc Mon Sep 17 00:00:00 2001
+From: Josef Bacik <jbacik@fusionio.com>
+Date: Wed, 17 Jul 2013 19:30:20 -0400
+Subject: Btrfs: re-add root to dead root list if we stop dropping it
+
+From: Josef Bacik <jbacik@fusionio.com>
+
+commit d29a9f629e009c9b90e5859bce581070fd6247fc upstream.
+
+If we stop dropping a root for whatever reason we need to add it back to the
+dead root list so that we will re-start the dropping next transaction commit.
+The other case this happens is if we recover a drop because we will add a root
+without adding it to the fs radix tree, so we can leak it's root and commit root
+extent buffer, adding this to the dead root list makes this cleanup happen.
+Thanks,
+
+Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
+Signed-off-by: Josef Bacik <jbacik@fusionio.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent-tree.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -6846,6 +6846,7 @@ int btrfs_drop_snapshot(struct btrfs_roo
+ int err = 0;
+ int ret;
+ int level;
++ bool root_dropped = false;
+
+ path = btrfs_alloc_path();
+ if (!path) {
+@@ -7016,12 +7017,22 @@ int btrfs_drop_snapshot(struct btrfs_roo
+ free_extent_buffer(root->commit_root);
+ kfree(root);
+ }
++ root_dropped = true;
+ out_end_trans:
+ btrfs_end_transaction_throttle(trans, tree_root);
+ out_free:
+ kfree(wc);
+ btrfs_free_path(path);
+ out:
++ /*
++ * So if we need to stop dropping the snapshot for whatever reason we
++ * need to make sure to add it back to the dead root list so that we
++ * keep trying to do the work later. This also cleans up roots if we
++ * don't have it in the radix (like when we recover after a power fail
++ * or unmount) so we don't leak memory.
++ */
++ if (root_dropped == false)
++ btrfs_add_dead_root(root);
+ if (err)
+ btrfs_std_error(root->fs_info, err);
+ return err;
--- /dev/null
+From b1bf2de07271932326af847a3c6a01fdfd29d4be Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 10 Jul 2013 23:41:16 +0100
+Subject: dm verity: fix inability to use a few specific devices sizes
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit b1bf2de07271932326af847a3c6a01fdfd29d4be upstream.
+
+Fix a boundary condition that caused failure for certain device sizes.
+
+The problem is reported at
+ http://code.google.com/p/cryptsetup/issues/detail?id=160
+
+For certain device sizes the number of hashes at a specific level was
+calculated incorrectly.
+
+It happens for example for a device with data and metadata block size 4096
+that has 16385 blocks and algorithm sha256.
+
+The user can test if he is affected by this bug by running the
+"veritysetup verify" command and also by activating the dm-verity kernel
+driver and reading the whole block device. If it passes without an error,
+then the user is not affected.
+
+The condition for the bug is:
+
+Split the total number of data blocks (data_block_bits) into bit strings,
+each string has hash_per_block_bits bits. hash_per_block_bits is
+rounddown(log2(metadata_block_size/hash_digest_size)). Equivalently, you
+can say that you convert data_blocks_bits to 2^hash_per_block_bits base.
+
+If there some zero bit string below the most significant bit string and at
+least one bit below this zero bit string is set, then the bug happens.
+
+The same bug exists in the userspace veritysetup tool, so you must use
+fixed veritysetup too if you want to use devices that are affected by
+this boundary condition.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: Milan Broz <gmazyland@gmail.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-verity.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-verity.c
++++ b/drivers/md/dm-verity.c
+@@ -813,9 +813,8 @@ static int verity_ctr(struct dm_target *
+ for (i = v->levels - 1; i >= 0; i--) {
+ sector_t s;
+ v->hash_level_block[i] = hash_position;
+- s = verity_position_at_level(v, v->data_blocks, i);
+- s = (s >> v->hash_per_block_bits) +
+- !!(s & ((1 << v->hash_per_block_bits) - 1));
++ s = (v->data_blocks + ((sector_t)1 << ((i + 1) * v->hash_per_block_bits)) - 1)
++ >> ((i + 1) * v->hash_per_block_bits);
+ if (hash_position + s < hash_position) {
+ ti->error = "Hash device offset overflow";
+ r = -E2BIG;
--- /dev/null
+From bb9696192826a7d9279caf872e95b41bc26c7eff Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 22 Jul 2013 16:53:36 -0400
+Subject: libata: make it clear that sata_inic162x is experimental
+
+From: Tejun Heo <tj@kernel.org>
+
+commit bb9696192826a7d9279caf872e95b41bc26c7eff upstream.
+
+sata_inic162x never reached a state where it's reliable enough for
+production use and data corruption is a relatively common occurrence.
+Make the driver generate warning about the issues and mark the Kconfig
+option as experimental.
+
+If the situation doesn't improve, we'd be better off making it depend
+on CONFIG_BROKEN. Let's wait for several cycles and see if the kernel
+message draws any attention.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: Martin Braure de Calignon <braurede@free.fr>
+Reported-by: Ben Hutchings <ben@decadent.org.uk>
+Reported-by: risc4all@yahoo.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/Kconfig | 2 +-
+ drivers/ata/sata_inic162x.c | 14 ++++++++++++++
+ 2 files changed, 15 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/Kconfig
++++ b/drivers/ata/Kconfig
+@@ -93,7 +93,7 @@ config SATA_FSL
+ If unsure, say N.
+
+ config SATA_INIC162X
+- tristate "Initio 162x SATA support"
++ tristate "Initio 162x SATA support (Very Experimental)"
+ depends on PCI
+ help
+ This option enables support for Initio 162x Serial ATA.
+--- a/drivers/ata/sata_inic162x.c
++++ b/drivers/ata/sata_inic162x.c
+@@ -6,6 +6,18 @@
+ *
+ * This file is released under GPL v2.
+ *
++ * **** WARNING ****
++ *
++ * This driver never worked properly and unfortunately data corruption is
++ * relatively common. There isn't anyone working on the driver and there's
++ * no support from the vendor. Do not use this driver in any production
++ * environment.
++ *
++ * http://thread.gmane.org/gmane.linux.debian.devel.bugs.rc/378525/focus=54491
++ * https://bugzilla.kernel.org/show_bug.cgi?id=60565
++ *
++ * *****************
++ *
+ * This controller is eccentric and easily locks up if something isn't
+ * right. Documentation is available at initio's website but it only
+ * documents registers (not programming model).
+@@ -809,6 +821,8 @@ static int inic_init_one(struct pci_dev
+
+ ata_print_version_once(&pdev->dev, DRV_VERSION);
+
++ dev_alert(&pdev->dev, "inic162x support is broken with common data corruption issues and will be disabled by default, contact linux-ide@vger.kernel.org if in production use\n");
++
+ /* alloc host */
+ host = ata_host_alloc_pinfo(&pdev->dev, ppi, NR_PORTS);
+ hpriv = devm_kzalloc(&pdev->dev, sizeof(*hpriv), GFP_KERNEL);
--- /dev/null
+From 0e0ed6406e61434d3f38fb58aa8464ec4722b77e Mon Sep 17 00:00:00 2001
+From: Anton Blanchard <anton@samba.org>
+Date: Mon, 15 Jul 2013 14:04:50 +1000
+Subject: powerpc/modules: Module CRC relocation fix causes perf issues
+
+From: Anton Blanchard <anton@samba.org>
+
+commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.
+
+Module CRCs are implemented as absolute symbols that get resolved by
+a linker script. We build an intermediate .o that contains an
+unresolved symbol for each CRC. genksysms parses this .o, calculates
+the CRCs and writes a linker script that "resolves" the symbols to
+the calculated CRC.
+
+Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
+that need relocating and relocates them at boot. Commit d4703aef
+(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
+added a hook to reverse the bogus relocations. Part of this patch
+created a symbol at 0x0:
+
+# head -2 /proc/kallsyms
+0000000000000000 T reloc_start
+c000000000000000 T .__start
+
+This reloc_start symbol is causing lots of confusion to perf. It
+thinks reloc_start is a massive function that stretches from 0x0 to
+0xc000000000000000 and we get various cryptic errors out of perf,
+including:
+
+problem incrementing symbol count, skipping event
+
+This patch removes the reloc_start linker script label and instead
+defines it as PHYSICAL_START. We also need to wrap it with
+CONFIG_PPC64 because the ppc32 kernel can set a non zero
+PHYSICAL_START at compile time and we wouldn't want to subtract
+it from the CRCs in that case.
+
+Signed-off-by: Anton Blanchard <anton@samba.org>
+Acked-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/include/asm/module.h | 5 ++---
+ arch/powerpc/kernel/vmlinux.lds.S | 3 ---
+ 2 files changed, 2 insertions(+), 6 deletions(-)
+
+--- a/arch/powerpc/include/asm/module.h
++++ b/arch/powerpc/include/asm/module.h
+@@ -87,10 +87,9 @@ struct exception_table_entry;
+ void sort_ex_table(struct exception_table_entry *start,
+ struct exception_table_entry *finish);
+
+-#ifdef CONFIG_MODVERSIONS
++#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
+ #define ARCH_RELOCATES_KCRCTAB
+-
+-extern const unsigned long reloc_start[];
++#define reloc_start PHYSICAL_START
+ #endif
+ #endif /* __KERNEL__ */
+ #endif /* _ASM_POWERPC_MODULE_H */
+--- a/arch/powerpc/kernel/vmlinux.lds.S
++++ b/arch/powerpc/kernel/vmlinux.lds.S
+@@ -38,9 +38,6 @@ jiffies = jiffies_64 + 4;
+ #endif
+ SECTIONS
+ {
+- . = 0;
+- reloc_start = .;
+-
+ . = KERNELBASE;
+
+ /*
--- /dev/null
+From c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 Mon Sep 17 00:00:00 2001
+From: Saurav Kashyap <saurav.kashyap@qlogic.com>
+Date: Fri, 12 Jul 2013 14:47:51 -0400
+Subject: SCSI: qla2xxx: Properly set the tagging for commands.
+
+From: Saurav Kashyap <saurav.kashyap@qlogic.com>
+
+commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream.
+
+This fixes a regression where Xyratex controllers and disks were lost by the
+driver:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=59601
+
+Reported-by: Jack Hill <jackhill@jackhill.us>
+Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
+Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_iocb.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_iocb.c
++++ b/drivers/scsi/qla2xxx/qla_iocb.c
+@@ -423,6 +423,8 @@ qla2x00_start_scsi(srb_t *sp)
+ __constant_cpu_to_le16(CF_SIMPLE_TAG);
+ break;
+ }
++ } else {
++ cmd_pkt->control_flags = __constant_cpu_to_le16(CF_SIMPLE_TAG);
+ }
+
+ /* Load SCSI command packet. */
+@@ -1331,11 +1333,11 @@ qla24xx_build_scsi_crc_2_iocbs(srb_t *sp
+ fcp_cmnd->task_attribute = TSK_ORDERED;
+ break;
+ default:
+- fcp_cmnd->task_attribute = 0;
++ fcp_cmnd->task_attribute = TSK_SIMPLE;
+ break;
+ }
+ } else {
+- fcp_cmnd->task_attribute = 0;
++ fcp_cmnd->task_attribute = TSK_SIMPLE;
+ }
+
+ cmd_pkt->fcp_rsp_dseg_len = 0; /* Let response come in status iocb */
+@@ -1541,7 +1543,12 @@ qla24xx_start_scsi(srb_t *sp)
+ case ORDERED_QUEUE_TAG:
+ cmd_pkt->task = TSK_ORDERED;
+ break;
++ default:
++ cmd_pkt->task = TSK_SIMPLE;
++ break;
+ }
++ } else {
++ cmd_pkt->task = TSK_SIMPLE;
+ }
+
+ /* Load SCSI command packet. */
--- /dev/null
+From 085b513f97d8d799d28491239be4b451bcd8c2c5 Mon Sep 17 00:00:00 2001
+From: "Ewan D. Milne" <emilne@redhat.com>
+Date: Fri, 2 Nov 2012 09:38:34 -0400
+Subject: SCSI: sd: fix crash when UA received on DIF enabled device
+
+From: "Ewan D. Milne" <emilne@redhat.com>
+
+commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream.
+
+sd_prep_fn will allocate a larger CDB for the command via mempool_alloc
+for devices using DIF type 2 protection. This CDB was being freed
+in sd_done, which results in a kernel crash if the command is retried
+due to a UNIT ATTENTION. This change moves the code to free the larger
+CDB into sd_unprep_fn instead, which is invoked after the request is
+complete.
+
+It is no longer necessary to call scsi_print_command separately for
+this case as the ->cmnd will no longer be NULL in the normal code path.
+
+Also removed conditional test for DIF type 2 when freeing the larger
+CDB because the protection_type could have been changed via sysfs while
+the command was executing.
+
+Signed-off-by: Ewan D. Milne <emilne@redhat.com>
+Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sd.c | 22 +++++++---------------
+ 1 file changed, 7 insertions(+), 15 deletions(-)
+
+--- a/drivers/scsi/sd.c
++++ b/drivers/scsi/sd.c
+@@ -672,10 +672,17 @@ static int scsi_setup_flush_cmnd(struct
+
+ static void sd_unprep_fn(struct request_queue *q, struct request *rq)
+ {
++ struct scsi_cmnd *SCpnt = rq->special;
++
+ if (rq->cmd_flags & REQ_DISCARD) {
+ free_page((unsigned long)rq->buffer);
+ rq->buffer = NULL;
+ }
++ if (SCpnt->cmnd != rq->cmd) {
++ mempool_free(SCpnt->cmnd, sd_cdb_pool);
++ SCpnt->cmnd = NULL;
++ SCpnt->cmd_len = 0;
++ }
+ }
+
+ /**
+@@ -1539,21 +1546,6 @@ static int sd_done(struct scsi_cmnd *SCp
+ if (rq_data_dir(SCpnt->request) == READ && scsi_prot_sg_count(SCpnt))
+ sd_dif_complete(SCpnt, good_bytes);
+
+- if (scsi_host_dif_capable(sdkp->device->host, sdkp->protection_type)
+- == SD_DIF_TYPE2_PROTECTION && SCpnt->cmnd != SCpnt->request->cmd) {
+-
+- /* We have to print a failed command here as the
+- * extended CDB gets freed before scsi_io_completion()
+- * is called.
+- */
+- if (result)
+- scsi_print_command(SCpnt);
+-
+- mempool_free(SCpnt->cmnd, sd_cdb_pool);
+- SCpnt->cmnd = NULL;
+- SCpnt->cmd_len = 0;
+- }
+-
+ return good_bytes;
+ }
+
usb-storage-add-microvault-flash-drive-to-unusual_devs.patch
asoc-max98088-fix-element-type-of-the-register-cache.patch
asoc-wm8962-remove-remaining-direct-register-cache-accesses.patch
+scsi-sd-fix-crash-when-ua-received-on-dif-enabled-device.patch
+scsi-qla2xxx-properly-set-the-tagging-for-commands.patch
+tracing-fix-irqs-off-tag-display-in-syscall-tracing.patch
+usb-host-xhci-enable-xhci_spurious_success-for-all-controllers-with-xhci-1.0.patch
+xhci-fix-null-pointer-dereference-on-ring_doorbell_for_active_rings.patch
+xhci-avoid-null-pointer-deref-when-host-dies.patch
+usb-dwc3-fix-wrong-bit-mask-in-dwc3_event_type.patch
+usb-dwc3-gadget-don-t-prevent-gadget-from-being-probed-if-we-fail.patch
+usb-ti_usb_3410_5052-fix-dynamic-id-matching.patch
+usb-misc-add-manhattan-hi-speed-usb-dvi-converter-to-sisusbvga.patch
+usb-clear-both-buffers-when-clearing-a-control-transfer-tt-buffer.patch
+staging-comedi-comedi_cancel-ioctl-should-wake-up-read-write.patch
+btrfs-fix-lock-leak-when-resuming-snapshot-deletion.patch
+btrfs-re-add-root-to-dead-root-list-if-we-stop-dropping-it.patch
+xen-blkback-check-device-permissions-before-allowing-op_discard.patch
+ata-fix-dvd-not-dectected-at-some-platform-with-wellsburg-pch.patch
+libata-make-it-clear-that-sata_inic162x-is-experimental.patch
+powerpc-modules-module-crc-relocation-fix-causes-perf-issues.patch
+acpi-memhotplug-fix-a-stale-pointer-in-error-path.patch
+dm-verity-fix-inability-to-use-a-few-specific-devices-sizes.patch
--- /dev/null
+From 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Mon, 8 Jul 2013 13:36:19 +0100
+Subject: staging: comedi: COMEDI_CANCEL ioctl should wake up read/write
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream.
+
+Comedi devices can do blocking read() or write() (or poll()) if an
+asynchronous command has been set up, blocking for data (for read()) or
+buffer space (for write()). Various events associated with the
+asynchronous command will wake up the blocked reader or writer (or
+poller). It is also possible to force the asynchronous command to
+terminate by issuing a `COMEDI_CANCEL` ioctl. That shuts down the
+asynchronous command, but does not currently wake up the blocked reader
+or writer (or poller). If the blocked task could be woken up, it would
+see that the command is no longer active and return. The caller of the
+`COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by
+sending a signal, but that's a nasty workaround.
+
+Change `do_cancel_ioctl()` to wake up the wait queue after it returns
+from `do_cancel()`. `do_cancel()` can propagate an error return value
+from the low-level comedi driver's cancel routine, but it always shuts
+the command down regardless, so `do_cancel_ioctl()` can wake up he wait
+queue regardless of the return value from `do_cancel()`.
+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/comedi_fops.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/comedi/comedi_fops.c
++++ b/drivers/staging/comedi/comedi_fops.c
+@@ -1370,6 +1370,7 @@ static int do_cancel_ioctl(struct comedi
+ void *file)
+ {
+ struct comedi_subdevice *s;
++ int ret;
+
+ if (arg >= dev->n_subdevices)
+ return -EINVAL;
+@@ -1386,7 +1387,11 @@ static int do_cancel_ioctl(struct comedi
+ if (s->busy != file)
+ return -EBUSY;
+
+- return do_cancel(dev, s);
++ ret = do_cancel(dev, s);
++ if (comedi_get_subdevice_runflags(s) & SRF_USER)
++ wake_up_interruptible(&s->async->wait_head);
++
++ return ret;
+ }
+
+ /*
--- /dev/null
+From jovi.zhangwei@huawei.com Thu Aug 1 10:53:20 2013
+From: "zhangwei(Jovi)" <jovi.zhangwei@huawei.com>
+Date: Mon, 29 Jul 2013 09:33:58 +0800
+Subject: tracing: Fix irqs-off tag display in syscall tracing
+To: Greg KH <gregkh@linuxfoundation.org>
+Cc: Ben Hutchings <ben@decadent.org.uk>, Steven Rostedt <rostedt@goodmis.org>, <stable@vger.kernel.org>
+Message-ID: <51F5C686.4020608@huawei.com>
+
+From: "zhangwei(Jovi)" <jovi.zhangwei@huawei.com>
+
+commit 11034ae9c20f4057a6127fc965906417978e69b2 upstream
+
+Initialization of variable irq_flags and pc was missed when backport
+11034ae9c to linux-3.0.y and linux-3.4.y, my fault.
+
+Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_syscalls.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/trace_syscalls.c
++++ b/kernel/trace/trace_syscalls.c
+@@ -358,6 +358,9 @@ void ftrace_syscall_exit(void *ignore, s
+ if (!sys_data)
+ return;
+
++ local_save_flags(irq_flags);
++ pc = preempt_count();
++
+ event = trace_current_buffer_lock_reserve(&buffer,
+ sys_data->exit_event->event.type, sizeof(*entry),
+ irq_flags, pc);
--- /dev/null
+From 2c7b871b9102c497ba8f972aa5d38532f05b654d Mon Sep 17 00:00:00 2001
+From: William Gulland <wgulland@google.com>
+Date: Thu, 27 Jun 2013 16:10:20 -0700
+Subject: usb: Clear both buffers when clearing a control transfer TT buffer.
+
+From: William Gulland <wgulland@google.com>
+
+commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
+
+Control transfers have both IN and OUT (or SETUP) packets, so when
+clearing TT buffers for a control transfer it's necessary to send
+two HUB_CLEAR_TT_BUFFER requests to the hub.
+
+Signed-off-by: William Gulland <wgulland@google.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hub.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -488,6 +488,15 @@ resubmit:
+ static inline int
+ hub_clear_tt_buffer (struct usb_device *hdev, u16 devinfo, u16 tt)
+ {
++ /* Need to clear both directions for control ep */
++ if (((devinfo >> 11) & USB_ENDPOINT_XFERTYPE_MASK) ==
++ USB_ENDPOINT_XFER_CONTROL) {
++ int status = usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
++ HUB_CLEAR_TT_BUFFER, USB_RT_PORT,
++ devinfo ^ 0x8000, tt, NULL, 0, 1000);
++ if (status)
++ return status;
++ }
+ return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
+ HUB_CLEAR_TT_BUFFER, USB_RT_PORT, devinfo,
+ tt, NULL, 0, 1000);
--- /dev/null
+From 1974d494dea05ea227cb42f5e918828801e237aa Mon Sep 17 00:00:00 2001
+From: Huang Rui <ray.huang@amd.com>
+Date: Thu, 27 Jun 2013 01:08:11 +0800
+Subject: usb: dwc3: fix wrong bit mask in dwc3_event_type
+
+From: Huang Rui <ray.huang@amd.com>
+
+commit 1974d494dea05ea227cb42f5e918828801e237aa upstream.
+
+Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
+Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
+bit is 1, the event is represented Device-Specific Event, then use
+[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
+and we can see the reserved8_31 variable name which means from 8 to 31
+bits marked reserved, actually there are 24 bits not 25 bits between
+that. And 1 + 7 + 24 = 32, the event size is 4 byes.
+
+So in dwc3_event_type, the bit mask should be:
+is_devspec [0] 1 bit
+type [7:1] 7 bits
+reserved8_31 [31:8] 24 bits
+
+This patch should be backported to kernels as old as 3.2, that contain
+the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce
+DesignWare USB3 DRD Driver".
+
+Signed-off-by: Huang Rui <ray.huang@amd.com>
+Signed-off-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/core.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/dwc3/core.h
++++ b/drivers/usb/dwc3/core.h
+@@ -641,8 +641,8 @@ struct dwc3 {
+
+ struct dwc3_event_type {
+ u32 is_devspec:1;
+- u32 type:6;
+- u32 reserved8_31:25;
++ u32 type:7;
++ u32 reserved8_31:24;
+ } __packed;
+
+ #define DWC3_DEPEVT_XFERCOMPLETE 0x01
--- /dev/null
+From cdcedd6981194e511cc206887db661d016069d68 Mon Sep 17 00:00:00 2001
+From: Felipe Balbi <balbi@ti.com>
+Date: Mon, 15 Jul 2013 12:36:35 +0300
+Subject: usb: dwc3: gadget: don't prevent gadget from being probed if we fail
+
+From: Felipe Balbi <balbi@ti.com>
+
+commit cdcedd6981194e511cc206887db661d016069d68 upstream.
+
+In case we fail our ->udc_start() callback, we
+should be ready to accept another modprobe following
+the failed one.
+
+We had forgotten to clear dwc->gadget_driver back
+to NULL and, because of that, we were preventing
+gadget driver modprobe from being retried.
+
+Signed-off-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc3/gadget.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/dwc3/gadget.c
++++ b/drivers/usb/dwc3/gadget.c
+@@ -1393,6 +1393,7 @@ err1:
+ __dwc3_gadget_ep_disable(dwc->eps[0]);
+
+ err0:
++ dwc->gadget_driver = NULL;
+ spin_unlock_irqrestore(&dwc->lock, flags);
+
+ return ret;
--- /dev/null
+From 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 Mon Sep 17 00:00:00 2001
+From: George Cherian <george.cherian@ti.com>
+Date: Mon, 1 Jul 2013 10:59:12 +0530
+Subject: usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
+
+From: George Cherian <george.cherian@ti.com>
+
+commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream.
+
+Xhci controllers with hci_version > 0.96 gives spurious success
+events on short packet completion. During webcam capture the
+"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
+The same application works fine with synopsis controllers hci_version 0.96.
+The same issue is seen with Intel Pantherpoint xhci controller. So enabling
+this quirk in xhci_gen_setup if controller verion is greater than 0.96.
+For xhci-pci move the quirk to much generic place xhci_gen_setup.
+
+Note from Sarah:
+
+The xHCI 1.0 spec changed how hardware handles short packets. The HW
+will notify SW of the TRB where the short packet occurred, and it will
+also give a successful status for the last TRB in a TD (the one with the
+IOC flag set). On the second successful status, that warning will be
+triggered in the driver.
+
+Software is now supposed to not assume the TD is not completed until it
+gets that last successful status. That means we have a slight race
+condition, although it should have little practical impact. This patch
+papers over that issue.
+
+It's on my long-term to-do list to fix this race condition, but it is a
+much more involved patch that will probably be too big for stable. This
+patch is needed for stable to avoid serious log spam.
+
+This patch should be backported to kernels as old as 3.0, that
+contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci:
+Ignore spurious successful event."
+
+The patch will have to be modified for kernels older than 3.2, since
+that kernel added the xhci_gen_setup function for xhci platform devices.
+The correct conflict resolution for kernels older than 3.2 is to set
+XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
+
+Signed-off-by: George Cherian <george.cherian@ti.com>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-pci.c | 1 -
+ drivers/usb/host/xhci.c | 7 +++++++
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -89,7 +89,6 @@ static void xhci_pci_quirks(struct devic
+ xhci->quirks |= XHCI_AMD_PLL_FIX;
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+ pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
+- xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
+ xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
+ xhci->limit_active_eps = 64;
+ xhci->quirks |= XHCI_SW_BW_CHECKING;
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -4194,6 +4194,13 @@ int xhci_gen_setup(struct usb_hcd *hcd,
+
+ get_quirks(dev, xhci);
+
++ /* In xhci controllers which follow xhci 1.0 spec gives a spurious
++ * success event after a short transfer. This quirk will ignore such
++ * spurious event.
++ */
++ if (xhci->hci_version > 0x96)
++ xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
++
+ /* Make sure the HC is halted. */
+ retval = xhci_halt(xhci);
+ if (retval)
--- /dev/null
+From 58fc90db8261b571c026bb8bf23aad48a7233118 Mon Sep 17 00:00:00 2001
+From: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
+Date: Thu, 4 Jul 2013 21:47:52 +0000
+Subject: USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga
+
+From: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
+
+commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream.
+
+Signed-off-by: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/misc/sisusbvga/sisusb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/misc/sisusbvga/sisusb.c
++++ b/drivers/usb/misc/sisusbvga/sisusb.c
+@@ -3247,6 +3247,7 @@ static const struct usb_device_id sisusb
+ { USB_DEVICE(0x0711, 0x0903) },
+ { USB_DEVICE(0x0711, 0x0918) },
+ { USB_DEVICE(0x0711, 0x0920) },
++ { USB_DEVICE(0x0711, 0x0950) },
+ { USB_DEVICE(0x182d, 0x021c) },
+ { USB_DEVICE(0x182d, 0x0269) },
+ { }
--- /dev/null
+From 1fad56424f5ad3ce4973505a357212b2e2282b3f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <jhovold@gmail.com>
+Date: Fri, 28 Jun 2013 12:24:26 +0200
+Subject: USB: ti_usb_3410_5052: fix dynamic-id matching
+
+From: Johan Hovold <jhovold@gmail.com>
+
+commit 1fad56424f5ad3ce4973505a357212b2e2282b3f upstream.
+
+The driver failed to take the dynamic ids into account when determining
+the device type and therefore all devices were detected as 2-port
+devices when using the dynamic-id interface.
+
+Match on the usb-serial-driver field instead of doing redundant id-table
+searches.
+
+Reported-by: Anders Hammarquist <iko@iko.pp.se>
+Signed-off-by: Johan Hovold <jhovold@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/ti_usb_3410_5052.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/serial/ti_usb_3410_5052.c
++++ b/drivers/usb/serial/ti_usb_3410_5052.c
+@@ -390,7 +390,7 @@ static int ti_startup(struct usb_serial
+ usb_set_serial_data(serial, tdev);
+
+ /* determine device type */
+- if (usb_match_id(serial->interface, ti_id_table_3410))
++ if (serial->type == &ti_1port_device)
+ tdev->td_is_3410 = 1;
+ dbg("%s - device type is %s", __func__,
+ tdev->td_is_3410 ? "3410" : "5052");
--- /dev/null
+From 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 Mon Sep 17 00:00:00 2001
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Date: Wed, 16 Jan 2013 11:33:52 -0500
+Subject: xen/blkback: Check device permissions before allowing OP_DISCARD
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+
+commit 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 upstream.
+
+We need to make sure that the device is not RO or that
+the request is not past the number of sectors we want to
+issue the DISCARD operation for.
+
+This fixes CVE-2013-2140.
+
+Acked-by: Jan Beulich <JBeulich@suse.com>
+Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
+[v1: Made it pr_warn instead of pr_debug]
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/xen-blkback/blkback.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/drivers/block/xen-blkback/blkback.c
++++ b/drivers/block/xen-blkback/blkback.c
+@@ -399,7 +399,18 @@ static int dispatch_discard_io(struct xe
+ int status = BLKIF_RSP_OKAY;
+ struct block_device *bdev = blkif->vbd.bdev;
+ unsigned long secure;
++ struct phys_req preq;
+
++ preq.sector_number = req->u.discard.sector_number;
++ preq.nr_sects = req->u.discard.nr_sectors;
++
++ err = xen_vbd_translate(&preq, blkif, WRITE);
++ if (err) {
++ pr_warn(DRV_PFX "access denied: DISCARD [%llu->%llu] on dev=%04x\n",
++ preq.sector_number,
++ preq.sector_number + preq.nr_sects, blkif->vbd.pdevice);
++ goto fail_response;
++ }
+ blkif->st_ds_req++;
+
+ xen_blkif_get(blkif);
+@@ -410,7 +421,7 @@ static int dispatch_discard_io(struct xe
+ err = blkdev_issue_discard(bdev, req->u.discard.sector_number,
+ req->u.discard.nr_sectors,
+ GFP_KERNEL, secure);
+-
++fail_response:
+ if (err == -EOPNOTSUPP) {
+ pr_debug(DRV_PFX "discard op failed, not supported\n");
+ status = BLKIF_RSP_EOPNOTSUPP;
--- /dev/null
+From 203a86613fb3bf2767335659513fa98563a3eb71 Mon Sep 17 00:00:00 2001
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Date: Wed, 24 Jul 2013 10:27:13 -0700
+Subject: xhci: Avoid NULL pointer deref when host dies.
+
+From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+
+commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream.
+
+When the host controller fails to respond to an Enable Slot command, and
+the host fails to respond to the register write to abort the command
+ring, the xHCI driver will assume the host is dead, and call
+usb_hc_died().
+
+The USB device's slot_id is still set to zero, and the pointer stored at
+xhci->devs[0] will always be NULL. The call to xhci_check_args in
+xhci_free_dev should have caught the NULL virt_dev pointer.
+
+However, xhci_free_dev is designed to free the xhci_virt_device
+structures, even if the host is dead, so that we don't leak kernel
+memory. xhci_free_dev checks the return value from the generic
+xhci_check_args function. If the return value is -ENODEV, it carries on
+trying to free the virtual device.
+
+The issue is that xhci_check_args looks at the host controller state
+before it looks at the xhci_virt_device pointer. It will return -ENIVAL
+because the host is dead, and xhci_free_dev will ignore the return
+value, and happily dereference the NULL xhci_virt_device pointer.
+
+The fix is to make sure that xhci_check_args checks the xhci_virt_device
+pointer before it checks the host state.
+
+See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
+further details. This patch doesn't solve the underlying issue, but
+will ensure we don't see any more NULL pointer dereferences because of
+the issue.
+
+This patch should be backported to kernels as old as 3.1, that
+contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
+submit commands or URBs to halted hosts."
+
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Reported-by: Vincent Thiele <vincentthiele@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -1162,9 +1162,6 @@ static int xhci_check_args(struct usb_hc
+ }
+
+ xhci = hcd_to_xhci(hcd);
+- if (xhci->xhc_state & XHCI_STATE_HALTED)
+- return -ENODEV;
+-
+ if (check_virt_dev) {
+ if (!udev->slot_id || !xhci->devs[udev->slot_id]) {
+ printk(KERN_DEBUG "xHCI %s called with unaddressed "
+@@ -1180,6 +1177,9 @@ static int xhci_check_args(struct usb_hc
+ }
+ }
+
++ if (xhci->xhc_state & XHCI_STATE_HALTED)
++ return -ENODEV;
++
+ return 1;
+ }
+
--- /dev/null
+From d66eaf9f89502971fddcb0de550b01fa6f409d83 Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <linux@rempel-privat.de>
+Date: Sun, 21 Jul 2013 15:36:19 +0200
+Subject: xhci: fix null pointer dereference on ring_doorbell_for_active_rings
+
+From: Oleksij Rempel <linux@rempel-privat.de>
+
+commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream.
+
+in some cases where device is attched to xhci port and do not responding,
+for example ath9k_htc with stalled firmware, kernel will
+crash on ring_doorbell_for_active_rings.
+This patch check if pointer exist before it is used.
+
+This patch should be backported to kernels as old as 2.6.35, that
+contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
+Correct assumptions about number of rings per endpoint"
+
+Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
+Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/xhci-ring.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -434,7 +434,7 @@ static void ring_doorbell_for_active_rin
+
+ /* A ring has pending URBs if its TD list is not empty */
+ if (!(ep->ep_state & EP_HAS_STREAMS)) {
+- if (!(list_empty(&ep->ring->td_list)))
++ if (ep->ring && !(list_empty(&ep->ring->td_list)))
+ xhci_ring_ep_doorbell(xhci, slot_id, ep_index, 0);
+ return;
+ }