--- /dev/null
+From 084c7189acb3f969c855536166042e27f5dd703f Mon Sep 17 00:00:00 2001
+From: Bing Zhao <bzhao@marvell.com>
+Date: Fri, 15 Mar 2013 18:47:07 -0700
+Subject: mwifiex: cancel cmd timer and free curr_cmd in shutdown process
+
+From: Bing Zhao <bzhao@marvell.com>
+
+commit 084c7189acb3f969c855536166042e27f5dd703f upstream.
+
+curr_cmd points to the command that is in processing or waiting
+for its command response from firmware. If the function shutdown
+happens to occur at this time we should cancel the cmd timer and
+put the command back to free queue.
+
+Tested-by: Marco Cesarano <marco@marvell.com>
+Signed-off-by: Bing Zhao <bzhao@marvell.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mwifiex/init.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/net/wireless/mwifiex/init.c
++++ b/drivers/net/wireless/mwifiex/init.c
+@@ -561,6 +561,14 @@ mwifiex_shutdown_drv(struct mwifiex_adap
+ return ret;
+ }
+
++ /* cancel current command */
++ if (adapter->curr_cmd) {
++ dev_warn(adapter->dev, "curr_cmd is still in processing\n");
++ del_timer(&adapter->cmd_timer);
++ mwifiex_insert_cmd_to_free_q(adapter, adapter->curr_cmd);
++ adapter->curr_cmd = NULL;
++ }
++
+ /* shut down mwifiex */
+ dev_dbg(adapter->dev, "info: shutdown mwifiex...\n");
+
--- /dev/null
+From 896ee0eee6261e30c3623be931c3f621428947df Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Wed, 20 Mar 2013 05:19:24 +0000
+Subject: net/irda: add missing error path release_sock call
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 896ee0eee6261e30c3623be931c3f621428947df upstream.
+
+This makes sure that release_sock is called for all error conditions in
+irda_getsockopt.
+
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Reported-by: Brad Spengler <spender@grsecurity.net>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/irda/af_irda.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/net/irda/af_irda.c
++++ b/net/irda/af_irda.c
+@@ -2584,8 +2584,10 @@ bed:
+ NULL, NULL, NULL);
+
+ /* Check if the we got some results */
+- if (!self->cachedaddr)
+- return -EAGAIN; /* Didn't find any devices */
++ if (!self->cachedaddr) {
++ err = -EAGAIN; /* Didn't find any devices */
++ goto out;
++ }
+ daddr = self->cachedaddr;
+ /* Cleanup */
+ self->cachedaddr = 0;
sysfs-fix-race-between-readdir-and-lseek.patch
sysfs-handle-failure-path-correctly-for-readdir.patch
b43-a-fix-for-dma-transmission-sequence-errors.patch
+xen-blkback-fix-dispatch_rw_block_io-error-path.patch
+usb-ftdi_sio-add-support-for-mitsubishi-fx-usb-aw-bd.patch
+vt-synchronize_rcu-under-spinlock-is-not-nice.patch
+mwifiex-cancel-cmd-timer-and-free-curr_cmd-in-shutdown-process.patch
+net-irda-add-missing-error-path-release_sock-call.patch
+usb-ehci-fix-bug-in-itd-sitd-dma-pool-allocation.patch
+usb-xhci-fix-trb-transfer-length-macro-used-for-event-trb.patch
--- /dev/null
+From 85ecd0322b9a1a9f451d9150e9460ab42fd17219 Mon Sep 17 00:00:00 2001
+From: Soeren Moch <smoch@web.de>
+Date: Fri, 22 Mar 2013 12:16:52 -0400
+Subject: USB: EHCI: fix bug in iTD/siTD DMA pool allocation
+
+From: Soeren Moch <smoch@web.de>
+
+commit 85ecd0322b9a1a9f451d9150e9460ab42fd17219 upstream.
+
+[Description written by Alan Stern]
+
+Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
+management of iTD and siTD structures. Some background: ehci-hcd
+gives each isochronous endpoint its own set of active and free itd's
+(or sitd's for full-speed devices). When a new itd is needed, it is
+taken from the head of the free list, if possible. However, itd's
+must not be used twice in a single frame because the hardware
+continues to access the data structure for the entire duration of a
+frame. Therefore if the itd at the head of the free list has its
+"frame" member equal to the current value of ehci->now_frame, it
+cannot be reused and instead a new itd is allocated from the DMA pool.
+The entries on the free list are not released back to the pool until
+the endpoint is no longer in use.
+
+The bug arises from the fact that sometimes an itd can be moved back
+onto the free list before itd->frame has been set properly. In
+Soeren's case, this happened because ehci-hcd can allocate one more
+itd than it actually needs for an URB; the extra itd may or may not be
+required depending on how the transfer aligns with a frame boundary.
+For example, an URB with 8 isochronous packets will cause two itd's to
+be allocated. If the URB is scheduled to start in microframe 3 of
+frame N then it will require both itds: one for microframes 3 - 7 of
+frame N and one for microframes 0 - 2 of frame N+1. But if the URB
+had been scheduled to start in microframe 0 then it would require only
+the first itd, which could cover microframes 0 - 7 of frame N. The
+second itd would be returned to the end of the free list.
+
+The itd allocation routine initializes the entire structure to 0, so
+the extra itd ends up on the free list with itd->frame set to 0
+instead of a meaningful value. After a while the itd reaches the head
+of the list, and occasionally this happens when ehci->now_frame is
+equal to 0. Then, even though it would be okay to reuse this itd, the
+driver thinks it must get another itd from the DMA pool.
+
+For as long as the isochronous endpoint remains in use, this flaw in
+the mechanism causes more and more itd's to be taken slowly from the
+DMA pool. Since none are released back, the pool eventually becomes
+exhausted.
+
+This reuslts in memory allocation failures, which typically show up
+during a long-running audio stream. Video might suffer the same
+effect.
+
+The fix is very simple. To prevent allocations from the pool when
+they aren't needed, make sure that itd's sent back to the free list
+prematurely have itd->frame set to an invalid value which can never be
+equal to ehci->now_frame.
+
+This should be applied to -stable kernels going back to 3.6.
+
+Signed-off-by: Soeren Moch <smoch@web.de>
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/host/ehci-sched.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/host/ehci-sched.c
++++ b/drivers/usb/host/ehci-sched.c
+@@ -1284,6 +1284,7 @@ itd_urb_transaction (
+
+ memset (itd, 0, sizeof *itd);
+ itd->itd_dma = itd_dma;
++ itd->frame = 9999; /* an invalid value */
+ list_add (&itd->itd_list, &sched->td_list);
+ }
+ spin_unlock_irqrestore (&ehci->lock, flags);
+@@ -1983,6 +1984,7 @@ sitd_urb_transaction (
+
+ memset (sitd, 0, sizeof *sitd);
+ sitd->sitd_dma = sitd_dma;
++ sitd->frame = 9999; /* an invalid value */
+ list_add (&sitd->sitd_list, &iso_sched->td_list);
+ }
+
--- /dev/null
+From 482b0b5d82bd916cc0c55a2abf65bdc69023b843 Mon Sep 17 00:00:00 2001
+From: Konstantin Holoborodko <klh.kernel@gmail.com>
+Date: Fri, 29 Mar 2013 00:06:13 +0900
+Subject: usb: ftdi_sio: Add support for Mitsubishi FX-USB-AW/-BD
+
+From: Konstantin Holoborodko <klh.kernel@gmail.com>
+
+commit 482b0b5d82bd916cc0c55a2abf65bdc69023b843 upstream.
+
+It enhances the driver for FTDI-based USB serial adapters
+to recognize Mitsubishi Electric Corp. USB/RS422 Converters
+as FT232BM chips and support them.
+https://search.meau.com/?q=FX-USB-AW
+
+Signed-off-by: Konstantin Holoborodko <klh.kernel@gmail.com>
+Tested-by: Konstantin Holoborodko <klh.kernel@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/serial/ftdi_sio.c | 1 +
+ drivers/usb/serial/ftdi_sio_ids.h | 7 +++++++
+ 2 files changed, 8 insertions(+)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -646,6 +646,7 @@ static struct usb_device_id id_table_com
+ { USB_DEVICE(FTDI_VID, FTDI_RM_CANVIEW_PID) },
+ { USB_DEVICE(ACTON_VID, ACTON_SPECTRAPRO_PID) },
+ { USB_DEVICE(CONTEC_VID, CONTEC_COM1USBH_PID) },
++ { USB_DEVICE(MITSUBISHI_VID, MITSUBISHI_FXUSB_PID) },
+ { USB_DEVICE(BANDB_VID, BANDB_USOTL4_PID) },
+ { USB_DEVICE(BANDB_VID, BANDB_USTL4_PID) },
+ { USB_DEVICE(BANDB_VID, BANDB_USO9ML2_PID) },
+--- a/drivers/usb/serial/ftdi_sio_ids.h
++++ b/drivers/usb/serial/ftdi_sio_ids.h
+@@ -584,6 +584,13 @@
+ #define CONTEC_COM1USBH_PID 0x8311 /* COM-1(USB)H */
+
+ /*
++ * Mitsubishi Electric Corp. (http://www.meau.com)
++ * Submitted by Konstantin Holoborodko
++ */
++#define MITSUBISHI_VID 0x06D3
++#define MITSUBISHI_FXUSB_PID 0x0284 /* USB/RS422 converters: FX-USB-AW/-BD */
++
++/*
+ * Definitions for B&B Electronics products.
+ */
+ #define BANDB_VID 0x0856 /* B&B Electronics Vendor ID */
--- /dev/null
+From 1c11a172cb30492f5f6a82c6e118fdcd9946c34f Mon Sep 17 00:00:00 2001
+From: Vivek Gautam <gautam.vivek@samsung.com>
+Date: Thu, 21 Mar 2013 12:06:48 +0530
+Subject: usb: xhci: Fix TRB transfer length macro used for Event TRB.
+
+From: Vivek Gautam <gautam.vivek@samsung.com>
+
+commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f upstream.
+
+Use proper macro while extracting TRB transfer length from
+Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
+for the same, and use it instead of TRB_LEN (bits 0:16) in
+case of event TRBs.
+
+This patch should be backported to kernels as old as 2.6.31, that
+contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci:
+Bulk transfer support". This patch will have issues applying to older
+kernels.
+
+Signed-off-by: Vivek gautam <gautam.vivek@samsung.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-ring.c | 24 ++++++++++++------------
+ drivers/usb/host/xhci.h | 4 ++++
+ 2 files changed, 16 insertions(+), 12 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1960,8 +1960,8 @@ static int process_ctrl_td(struct xhci_h
+ if (event_trb != ep_ring->dequeue &&
+ event_trb != td->last_trb)
+ td->urb->actual_length =
+- td->urb->transfer_buffer_length
+- - TRB_LEN(le32_to_cpu(event->transfer_len));
++ td->urb->transfer_buffer_length -
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+ else
+ td->urb->actual_length = 0;
+
+@@ -1993,7 +1993,7 @@ static int process_ctrl_td(struct xhci_h
+ /* Maybe the event was for the data stage? */
+ td->urb->actual_length =
+ td->urb->transfer_buffer_length -
+- TRB_LEN(le32_to_cpu(event->transfer_len));
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+ xhci_dbg(xhci, "Waiting for status "
+ "stage event\n");
+ return 0;
+@@ -2029,7 +2029,7 @@ static int process_isoc_td(struct xhci_h
+ /* handle completion code */
+ switch (trb_comp_code) {
+ case COMP_SUCCESS:
+- if (TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
++ if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
+ frame->status = 0;
+ break;
+ }
+@@ -2076,7 +2076,7 @@ static int process_isoc_td(struct xhci_h
+ len += TRB_LEN(le32_to_cpu(cur_trb->generic.field[2]));
+ }
+ len += TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
+- TRB_LEN(le32_to_cpu(event->transfer_len));
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+
+ if (trb_comp_code != COMP_STOP_INVAL) {
+ frame->actual_length = len;
+@@ -2134,7 +2134,7 @@ static int process_bulk_intr_td(struct x
+ case COMP_SUCCESS:
+ /* Double check that the HW transferred everything. */
+ if (event_trb != td->last_trb ||
+- TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
+ xhci_warn(xhci, "WARN Successful completion "
+ "on short TX\n");
+ if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
+@@ -2162,18 +2162,18 @@ static int process_bulk_intr_td(struct x
+ "%d bytes untransferred\n",
+ td->urb->ep->desc.bEndpointAddress,
+ td->urb->transfer_buffer_length,
+- TRB_LEN(le32_to_cpu(event->transfer_len)));
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
+ /* Fast path - was this the last TRB in the TD for this URB? */
+ if (event_trb == td->last_trb) {
+- if (TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
++ if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
+ td->urb->actual_length =
+ td->urb->transfer_buffer_length -
+- TRB_LEN(le32_to_cpu(event->transfer_len));
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+ if (td->urb->transfer_buffer_length <
+ td->urb->actual_length) {
+ xhci_warn(xhci, "HC gave bad length "
+ "of %d bytes left\n",
+- TRB_LEN(le32_to_cpu(event->transfer_len)));
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
+ td->urb->actual_length = 0;
+ if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
+ *status = -EREMOTEIO;
+@@ -2217,7 +2217,7 @@ static int process_bulk_intr_td(struct x
+ if (trb_comp_code != COMP_STOP_INVAL)
+ td->urb->actual_length +=
+ TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
+- TRB_LEN(le32_to_cpu(event->transfer_len));
++ EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
+ }
+
+ return finish_td(xhci, td, event_trb, event, ep, status, false);
+@@ -2283,7 +2283,7 @@ static int handle_tx_event(struct xhci_h
+ * transfer type
+ */
+ case COMP_SUCCESS:
+- if (TRB_LEN(le32_to_cpu(event->transfer_len)) == 0)
++ if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0)
+ break;
+ if (xhci->quirks & XHCI_TRUST_TX_LENGTH)
+ trb_comp_code = COMP_SHORT_TX;
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -831,6 +831,10 @@ struct xhci_transfer_event {
+ __le32 flags;
+ };
+
++/* Transfer event TRB length bit mask */
++/* bits 0:23 */
++#define EVENT_TRB_LEN(p) ((p) & 0xffffff)
++
+ /** Transfer Event bit fields **/
+ #define TRB_TO_EP_ID(p) (((p) >> 16) & 0x1f)
+
--- /dev/null
+From e8cd81693bbbb15db57d3c9aa7dd90eda4842874 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Tue, 26 Mar 2013 20:30:17 -0400
+Subject: vt: synchronize_rcu() under spinlock is not nice...
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit e8cd81693bbbb15db57d3c9aa7dd90eda4842874 upstream.
+
+vcs_poll_data_free() calls unregister_vt_notifier(), which calls
+atomic_notifier_chain_unregister(), which calls synchronize_rcu().
+Do it *after* we'd dropped ->f_lock.
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/vc_screen.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/vt/vc_screen.c
++++ b/drivers/tty/vt/vc_screen.c
+@@ -92,7 +92,7 @@ vcs_poll_data_free(struct vcs_poll_data
+ static struct vcs_poll_data *
+ vcs_poll_data_get(struct file *file)
+ {
+- struct vcs_poll_data *poll = file->private_data;
++ struct vcs_poll_data *poll = file->private_data, *kill = NULL;
+
+ if (poll)
+ return poll;
+@@ -121,10 +121,12 @@ vcs_poll_data_get(struct file *file)
+ file->private_data = poll;
+ } else {
+ /* someone else raced ahead of us */
+- vcs_poll_data_free(poll);
++ kill = poll;
+ poll = file->private_data;
+ }
+ spin_unlock(&file->f_lock);
++ if (kill)
++ vcs_poll_data_free(kill);
+
+ return poll;
+ }
--- /dev/null
+From 0e5e098ac22dae38f957e951b70d3cf73beff0f7 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <JBeulich@suse.com>
+Date: Mon, 11 Mar 2013 09:39:55 +0000
+Subject: xen-blkback: fix dispatch_rw_block_io() error path
+
+From: Jan Beulich <JBeulich@suse.com>
+
+commit 0e5e098ac22dae38f957e951b70d3cf73beff0f7 upstream.
+
+Commit 7708992 ("xen/blkback: Seperate the bio allocation and the bio
+submission") consolidated the pendcnt updates to just a single write,
+neglecting the fact that the error path relied on it getting set to 1
+up front (such that the decrement in __end_block_io_op() would actually
+drop the count to zero, triggering the necessary cleanup actions).
+
+Also remove a misleading and a stale (after said commit) comment.
+
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+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 | 7 +------
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+--- a/drivers/block/xen-blkback/blkback.c
++++ b/drivers/block/xen-blkback/blkback.c
+@@ -650,13 +650,7 @@ static int dispatch_rw_block_io(struct x
+ bio->bi_end_io = end_block_io_op;
+ }
+
+- /*
+- * We set it one so that the last submit_bio does not have to call
+- * atomic_inc.
+- */
+ atomic_set(&pending_req->pendcnt, nbio);
+-
+- /* Get a reference count for the disk queue and start sending I/O */
+ blk_start_plug(&plug);
+
+ for (i = 0; i < nbio; i++)
+@@ -684,6 +678,7 @@ static int dispatch_rw_block_io(struct x
+ fail_put_bio:
+ for (i = 0; i < nbio; i++)
+ bio_put(biolist[i]);
++ atomic_set(&pending_req->pendcnt, 1);
+ __end_block_io_op(pending_req, -EINVAL);
+ msleep(1); /* back off a bit */
+ return -EIO;
projects / thirdparty / kernel / stable-queue.git / commitdiff
