--- /dev/null
+From e6ee4b2b57a8e0d8e551031173de080b338d3969 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Wed, 19 Dec 2012 15:01:50 +0100
+Subject: ARM: 7607/1: realview: fix private peripheral memory base for EB rev. B boards
+
+From: Will Deacon <will.deacon@arm.com>
+
+commit e6ee4b2b57a8e0d8e551031173de080b338d3969 upstream.
+
+Commit 34ae6c96a6a7 ("ARM: 7298/1: realview: fix mapping of MPCore
+private memory region") accidentally broke the definition for the base
+address of the private peripheral region on revision B Realview-EB
+boards.
+
+This patch uses the correct address for REALVIEW_EB11MP_PRIV_MEM_BASE.
+
+Acked-by: Marc Zyngier <marc.zyngier@arm.com>
+Tested-by: Florian Fainelli <florian@openwrt.org>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-realview/include/mach/board-eb.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/mach-realview/include/mach/board-eb.h
++++ b/arch/arm/mach-realview/include/mach/board-eb.h
+@@ -47,7 +47,7 @@
+ #define REALVIEW_EB_USB_BASE 0x4F000000 /* USB */
+
+ #ifdef CONFIG_REALVIEW_EB_ARM11MP_REVB
+-#define REALVIEW_EB11MP_PRIV_MEM_BASE 0x1F000000
++#define REALVIEW_EB11MP_PRIV_MEM_BASE 0x10100000
+ #define REALVIEW_EB11MP_L220_BASE 0x10102000 /* L220 registers */
+ #define REALVIEW_EB11MP_SYS_PLD_CTRL1 0xD8 /* Register offset for MPCore sysctl */
+ #else
--- /dev/null
+From 7bf9b7bef881aac820bf1f2e9951a17b09bd7e04 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@ZenIV.linux.org.uk>
+Date: Sun, 16 Dec 2012 00:25:57 +0000
+Subject: ARM: missing ->mmap_sem around find_vma() in swp_emulate.c
+
+From: Al Viro <viro@ZenIV.linux.org.uk>
+
+commit 7bf9b7bef881aac820bf1f2e9951a17b09bd7e04 upstream.
+
+find_vma() is *not* safe when somebody else is removing vmas. Not just
+the return value might get bogus just as you are getting it (this instance
+doesn't try to dereference the resulting vma), the search itself can get
+buggered in rather spectacular ways. IOW, ->mmap_sem really, really is
+not optional here.
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/kernel/swp_emulate.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/kernel/swp_emulate.c
++++ b/arch/arm/kernel/swp_emulate.c
+@@ -109,10 +109,12 @@ static void set_segfault(struct pt_regs
+ {
+ siginfo_t info;
+
++ down_read(¤t->mm->mmap_sem);
+ if (find_vma(current->mm, addr) == NULL)
+ info.si_code = SEGV_MAPERR;
+ else
+ info.si_code = SEGV_ACCERR;
++ up_read(¤t->mm->mmap_sem);
+
+ info.si_signo = SIGSEGV;
+ info.si_errno = 0;
--- /dev/null
+From 864aa04cd02979c2c755cb28b5f4fe56039171c0 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Tue, 18 Sep 2012 19:18:35 +0100
+Subject: ARM: mm: use pteval_t to represent page protection values
+
+From: Will Deacon <will.deacon@arm.com>
+
+commit 864aa04cd02979c2c755cb28b5f4fe56039171c0 upstream.
+
+When updating the page protection map after calculating the user_pgprot
+value, the base protection map is temporarily stored in an unsigned long
+type, causing truncation of the protection bits when LPAE is enabled.
+This effectively means that calls to mprotect() will corrupt the upper
+page attributes, clearing the XN bit unconditionally.
+
+This patch uses pteval_t to store the intermediate protection values,
+preserving the upper bits for 64-bit descriptors.
+
+Acked-by: Nicolas Pitre <nico@linaro.org>
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mm/mmu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/mm/mmu.c
++++ b/arch/arm/mm/mmu.c
+@@ -497,7 +497,7 @@ static void __init build_mem_type_table(
+ #endif
+
+ for (i = 0; i < 16; i++) {
+- unsigned long v = pgprot_val(protection_map[i]);
++ pteval_t v = pgprot_val(protection_map[i]);
+ protection_map[i] = __pgprot(v | user_pgprot);
+ }
+
--- /dev/null
+From dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 Mon Sep 17 00:00:00 2001
+From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Date: Tue, 20 Nov 2012 23:25:54 -0200
+Subject: Bluetooth: Add missing lock nesting notation
+
+From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+
+commit dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 upstream.
+
+This patch fixes the following report, it happens when accepting rfcomm
+connections:
+
+[ 228.165378] =============================================
+[ 228.165378] [ INFO: possible recursive locking detected ]
+[ 228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G W
+[ 228.165378] ---------------------------------------------
+[ 228.165378] bluetoothd/1341 is trying to acquire lock:
+[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
+[<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
+[ 228.165378]
+[ 228.165378] but task is already holding lock:
+[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
+[<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
+[ 228.165378]
+[ 228.165378] other info that might help us debug this:
+[ 228.165378] Possible unsafe locking scenario:
+[ 228.165378]
+[ 228.165378] CPU0
+[ 228.165378] ----
+[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
+[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
+[ 228.165378]
+[ 228.165378] *** DEADLOCK ***
+[ 228.165378]
+[ 228.165378] May be due to missing lock nesting notation
+
+Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/rfcomm/sock.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/bluetooth/rfcomm/sock.c
++++ b/net/bluetooth/rfcomm/sock.c
+@@ -485,7 +485,7 @@ static int rfcomm_sock_accept(struct soc
+ long timeo;
+ int err = 0;
+
+- lock_sock(sk);
++ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
+
+ if (sk->sk_type != SOCK_STREAM) {
+ err = -EINVAL;
+@@ -522,7 +522,7 @@ static int rfcomm_sock_accept(struct soc
+
+ release_sock(sk);
+ timeo = schedule_timeout(timeo);
+- lock_sock(sk);
++ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
+ }
+ __set_current_state(TASK_RUNNING);
+ remove_wait_queue(sk_sleep(sk), &wait);
--- /dev/null
+From acd9454433e28c1a365d8b069813c35c1c3a8ac3 Mon Sep 17 00:00:00 2001
+From: Marcos Chaparro <marcos@mrkindustries.com.ar>
+Date: Tue, 6 Nov 2012 16:19:11 -0300
+Subject: Bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027]
+
+From: Marcos Chaparro <marcos@mrkindustries.com.ar>
+
+commit acd9454433e28c1a365d8b069813c35c1c3a8ac3 upstream.
+
+Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the
+devices list.
+Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth
+device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth
+[0cf3:3005].
+
+T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
+D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=0489 ProdID=e027 Rev= 0.01
+C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
+I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
+E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
+I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
+I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
+I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
+I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
+I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
+I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
+
+Signed-off-by: Marcos Chaparro <marcos@mrkindustries.com.ar>
+Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Cc: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/ath3k.c | 1 +
+ drivers/bluetooth/btusb.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/bluetooth/ath3k.c
++++ b/drivers/bluetooth/ath3k.c
+@@ -66,6 +66,7 @@ static struct usb_device_id ath3k_table[
+ { USB_DEVICE(0x13d3, 0x3304) },
+ { USB_DEVICE(0x0930, 0x0215) },
+ { USB_DEVICE(0x0489, 0xE03D) },
++ { USB_DEVICE(0x0489, 0xE027) },
+
+ /* Atheros AR9285 Malbec with sflash firmware */
+ { USB_DEVICE(0x03F0, 0x311D) },
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -130,6 +130,7 @@ static struct usb_device_id blacklist_ta
+ { USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
++ { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
+
+ /* Atheros AR9285 Malbec with sflash firmware */
+ { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
--- /dev/null
+From b9b5ef188e5a2222cfc16ef62a4703080750b451 Mon Sep 17 00:00:00 2001
+From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Date: Wed, 21 Nov 2012 00:50:21 -0200
+Subject: Bluetooth: cancel power_on work when unregistering the device
+
+From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+
+commit b9b5ef188e5a2222cfc16ef62a4703080750b451 upstream.
+
+We need to cancel the hci_power_on work in order to avoid it run when we
+try to free the hdev.
+
+[ 1434.201149] ------------[ cut here ]------------
+[ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
+[ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
+_power_on+0x0/0x90
+[ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-next-
+20121112-sasha-00018-g2f4ce0e #127
+[ 1434.210760] Call Trace:
+[ 1434.210760] [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
+[ 1434.210760] [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
+[ 1434.210760] [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
+[ 1434.210760] [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
+[ 1434.210760] [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
+[ 1434.210760] [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
+[ 1434.210760] [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
+[ 1434.210760] [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
+[ 1434.210760] [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
+[ 1434.210760] [<ffffffff8125eee7>] kfree+0x227/0x330
+[ 1434.210760] [<ffffffff83785db0>] bt_host_release+0x10/0x20
+[ 1434.210760] [<ffffffff81e539e5>] device_release+0x65/0xc0
+[ 1434.210760] [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
+[ 1434.210760] [<ffffffff819d39cd>] kobject_release+0xd/0x10
+[ 1434.210760] [<ffffffff819d33cc>] kobject_put+0x4c/0x60
+[ 1434.210760] [<ffffffff81e548b2>] put_device+0x12/0x20
+[ 1434.210760] [<ffffffff8376a334>] hci_free_dev+0x24/0x30
+[ 1434.210760] [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
+[ 1434.210760] [<ffffffff8127be12>] __fput+0x122/0x250
+[ 1434.210760] [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
+[ 1434.210760] [<ffffffff8127bf49>] ____fput+0x9/0x10
+[ 1434.210760] [<ffffffff81133402>] task_work_run+0xb2/0xf0
+[ 1434.210760] [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
+[ 1434.210760] [<ffffffff83bfb0ea>] int_signal+0x12/0x17
+[ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
+
+Reported-by: Sasha Levin <sasha.levin@oracle.com>
+Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/bluetooth/hci_core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/bluetooth/hci_core.c
++++ b/net/bluetooth/hci_core.c
+@@ -1866,6 +1866,8 @@ void hci_unregister_dev(struct hci_dev *
+ for (i = 0; i < NUM_REASSEMBLY; i++)
+ kfree_skb(hdev->reassembly[i]);
+
++ cancel_work_sync(&hdev->power_on);
++
+ if (!test_bit(HCI_INIT, &hdev->flags) &&
+ !test_bit(HCI_SETUP, &hdev->dev_flags)) {
+ hci_dev_lock(hdev);
--- /dev/null
+From 812089e01b9f65f90fc8fc670d8cce72a0e01fbb Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@amacapital.net>
+Date: Sat, 1 Dec 2012 12:37:20 -0800
+Subject: PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz
+
+From: Andy Lutomirski <luto@amacapital.net>
+
+commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream.
+
+Otherwise it fails like this on cards like the Transcend 16GB SDHC card:
+
+ mmc0: new SDHC card at address b368
+ mmcblk0: mmc0:b368 SDC 15.0 GiB
+ mmcblk0: error -110 sending status command, retrying
+ mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0
+
+Tested on my Lenovo x200 laptop.
+
+[bhelgaas: changelog]
+Signed-off-by: Andy Lutomirski <luto@amacapital.net>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Acked-by: Chris Ball <cjb@laptop.org>
+CC: Manoj Iyer <manoj.iyer@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 7 +++++--
+ include/linux/pci_ids.h | 1 +
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2708,7 +2708,7 @@ static void ricoh_mmc_fixup_r5c832(struc
+ if (PCI_FUNC(dev->devfn))
+ return;
+ /*
+- * RICOH 0xe823 SD/MMC card reader fails to recognize
++ * RICOH 0xe822 and 0xe823 SD/MMC card readers fail to recognize
+ * certain types of SD/MMC cards. Lowering the SD base
+ * clock frequency from 200Mhz to 50Mhz fixes this issue.
+ *
+@@ -2719,7 +2719,8 @@ static void ricoh_mmc_fixup_r5c832(struc
+ * 0xf9 - Key register for 0x150
+ * 0xfc - key register for 0xe1
+ */
+- if (dev->device == PCI_DEVICE_ID_RICOH_R5CE823) {
++ if (dev->device == PCI_DEVICE_ID_RICOH_R5CE822 ||
++ dev->device == PCI_DEVICE_ID_RICOH_R5CE823) {
+ pci_write_config_byte(dev, 0xf9, 0xfc);
+ pci_write_config_byte(dev, 0x150, 0x10);
+ pci_write_config_byte(dev, 0xf9, 0x00);
+@@ -2746,6 +2747,8 @@ static void ricoh_mmc_fixup_r5c832(struc
+ }
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
+ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5CE822, ricoh_mmc_fixup_r5c832);
++DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5CE822, ricoh_mmc_fixup_r5c832);
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5CE823, ricoh_mmc_fixup_r5c832);
+ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5CE823, ricoh_mmc_fixup_r5c832);
+ #endif /*CONFIG_MMC_RICOH_MMC*/
+--- a/include/linux/pci_ids.h
++++ b/include/linux/pci_ids.h
+@@ -1565,6 +1565,7 @@
+ #define PCI_DEVICE_ID_RICOH_RL5C476 0x0476
+ #define PCI_DEVICE_ID_RICOH_RL5C478 0x0478
+ #define PCI_DEVICE_ID_RICOH_R5C822 0x0822
++#define PCI_DEVICE_ID_RICOH_R5CE822 0xe822
+ #define PCI_DEVICE_ID_RICOH_R5CE823 0xe823
+ #define PCI_DEVICE_ID_RICOH_R5C832 0x0832
+ #define PCI_DEVICE_ID_RICOH_R5C843 0x0843
tcp-refine-syn-handling-in-tcp_validate_incoming.patch
tcp-tcp_replace_ts_recent-should-not-be-called-from-tcp_validate_incoming.patch
tcp-rfc-5961-5.2-blind-data-injection-attack-mitigation.patch
+arm-mm-use-pteval_t-to-represent-page-protection-values.patch
+arm-missing-mmap_sem-around-find_vma-in-swp_emulate.c.patch
+arm-7607-1-realview-fix-private-peripheral-memory-base-for-eb-rev.-b-boards.patch
+solos-pci-fix-double-free-of-tx-skb-in-dma-mode.patch
+pci-reduce-ricoh-0xe822-sd-card-reader-base-clock-frequency-to-50mhz.patch
+bluetooth-ath3k-add-support-for-vaio-vpceh.patch
+bluetooth-add-missing-lock-nesting-notation.patch
+bluetooth-cancel-power_on-work-when-unregistering-the-device.patch
--- /dev/null
+From cae49ede00ec3d0cda290b03fee55b72b49efc11 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw2@infradead.org>
+Date: Tue, 11 Dec 2012 14:57:14 +0000
+Subject: solos-pci: fix double-free of TX skb in DMA mode
+
+From: David Woodhouse <dwmw2@infradead.org>
+
+commit cae49ede00ec3d0cda290b03fee55b72b49efc11 upstream.
+
+We weren't clearing card->tx_skb[port] when processing the TX done interrupt.
+If there wasn't another skb ready to transmit immediately, this led to a
+double-free because we'd free it *again* next time we did have a packet to
+send.
+
+Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/atm/solos-pci.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/atm/solos-pci.c
++++ b/drivers/atm/solos-pci.c
+@@ -967,10 +967,11 @@ static uint32_t fpga_tx(struct solos_car
+ for (port = 0; tx_pending; tx_pending >>= 1, port++) {
+ if (tx_pending & 1) {
+ struct sk_buff *oldskb = card->tx_skb[port];
+- if (oldskb)
++ if (oldskb) {
+ pci_unmap_single(card->dev, SKB_CB(oldskb)->dma_addr,
+ oldskb->len, PCI_DMA_TODEVICE);
+-
++ card->tx_skb[port] = NULL;
++ }
+ spin_lock(&card->tx_queue_lock);
+ skb = skb_dequeue(&card->tx_queue[port]);
+ if (!skb)