Add commits to 3.4.y, up to 4.4-rc1
diff --git a/patches/acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch b/patches/acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch
new file mode 100644
index 0000000..c75d64d
--- /dev/null
+++ b/patches/acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch
@@ -0,0 +1,74 @@
+From 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a Mon Sep 17 00:00:00 2001
+From: Chen Yu <yu.c.chen@intel.com>
+Date: Sun, 25 Oct 2015 01:02:19 +0800
+Subject: ACPI: Use correct IRQ when uninstalling ACPI interrupt handler
+
+commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream.
+
+Currently when the system is trying to uninstall the ACPI interrupt
+handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
+However, the IRQ number that the ACPI interrupt handled is installed
+for comes from acpi_gsi_to_irq() and that is the number that should
+be used for the handler removal.
+
+Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
+as appropriate.
+
+Acked-by: Lv Zheng <lv.zheng@intel.com>
+Signed-off-by: Chen Yu <yu.c.chen@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+[lizf: Backported to 3.4: adjust context]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/acpi/osl.c   |    9 ++++++---
+ include/linux/acpi.h |    6 ++++++
+ 2 files changed, 12 insertions(+), 3 deletions(-)
+
+--- a/drivers/acpi/osl.c
++++ b/drivers/acpi/osl.c
+@@ -85,6 +85,7 @@ static void *acpi_irq_context;
+ static struct workqueue_struct *kacpid_wq;
+ static struct workqueue_struct *kacpi_notify_wq;
+ struct workqueue_struct *kacpi_hotplug_wq;
++unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
+ EXPORT_SYMBOL(kacpi_hotplug_wq);
+ 
+ /*
+@@ -612,17 +613,19 @@ acpi_os_install_interrupt_handler(u32 gs
+ 		acpi_irq_handler = NULL;
+ 		return AE_NOT_ACQUIRED;
+ 	}
++	acpi_sci_irq = irq;
+ 
+ 	return AE_OK;
+ }
+ 
+-acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler)
++acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
+ {
+-	if (irq != acpi_gbl_FADT.sci_interrupt)
++	if (gsi != acpi_gbl_FADT.sci_interrupt || !acpi_sci_irq_valid())
+ 		return AE_BAD_PARAMETER;
+ 
+-	free_irq(irq, acpi_irq);
++	free_irq(acpi_sci_irq, acpi_irq);
+ 	acpi_irq_handler = NULL;
++	acpi_sci_irq = INVALID_ACPI_IRQ;
+ 
+ 	return AE_OK;
+ }
+--- a/include/linux/acpi.h
++++ b/include/linux/acpi.h
+@@ -110,6 +110,12 @@ int acpi_unregister_ioapic(acpi_handle h
+ void acpi_irq_stats_init(void);
+ extern u32 acpi_irq_handled;
+ extern u32 acpi_irq_not_handled;
++extern unsigned int acpi_sci_irq;
++#define INVALID_ACPI_IRQ	((unsigned)-1)
++static inline bool acpi_sci_irq_valid(void)
++{
++	return acpi_sci_irq != INVALID_ACPI_IRQ;
++}
+ 
+ extern int sbf_port;
+ extern unsigned long acpi_realmode_flags;
diff --git a/patches/alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch b/patches/alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch
new file mode 100644
index 0000000..e5f8af1
--- /dev/null
+++ b/patches/alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch
@@ -0,0 +1,28 @@
+From c932b98c1e47312822d911c1bb76e81ef50e389c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 4 Nov 2015 22:39:16 +0100
+Subject: ALSA: hda - Apply pin fixup for HP ProBook 6550b
+
+commit c932b98c1e47312822d911c1bb76e81ef50e389c upstream.
+
+HP ProBook 6550b needs the same pin fixup applied to other HP B-series
+laptops with docks for making its headphone and dock headphone jacks
+working properly.  We just need to add the codec SSID to the list.
+
+Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=191971
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ sound/pci/hda/patch_sigmatel.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_sigmatel.c
++++ b/sound/pci/hda/patch_sigmatel.c
+@@ -4932,6 +4932,7 @@ static int find_mute_led_cfg(struct hda_
+ static int hp_blike_system(u32 subsystem_id)
+ {
+ 	switch (subsystem_id) {
++	case 0x103c1473: /* HP ProBook 6550b */
+ 	case 0x103c1520:
+ 	case 0x103c1521:
+ 	case 0x103c1523:
diff --git a/patches/alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch b/patches/alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch
new file mode 100644
index 0000000..23bd0de
--- /dev/null
+++ b/patches/alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch
@@ -0,0 +1,44 @@
+From cadd16ea33a938d49aee99edd4758cc76048b399 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 27 Oct 2015 14:21:51 +0100
+Subject: ALSA: hda - Disable 64bit address for Creative HDA controllers
+
+commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
+
+We've had many reports that some Creative sound cards with CA0132
+don't work well.  Some reported that it starts working after reloading
+the module, while some reported it starts working when a 32bit kernel
+is used.  All these facts seem implying that the chip fails to
+communicate when the buffer is located in 64bit address.
+
+This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
+flag to the corresponding PCI entries.  I casually had a chance to
+test an SB Recon3D board, and indeed this seems helping.
+
+Although this hasn't been tested on all Creative devices, it's safer
+to assume that this restriction applies to the rest of them, too.  So
+the flag is applied to all Creative entries.
+
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+[lizf: Backported to 3.4: drop the change to macro AZX_DCAPS_PRESET_CTHDA]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ sound/pci/hda/hda_intel.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -3144,11 +3144,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids)
+ 	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
+ 	  .class_mask = 0xffffff,
+ 	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
++	  AZX_DCAPS_NO_64BIT |
+ 	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
+ #else
+ 	/* this entry seems still valid -- i.e. without emu20kx chip */
+ 	{ PCI_DEVICE(0x1102, 0x0009),
+ 	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
++	  AZX_DCAPS_NO_64BIT |
+ 	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
+ #endif
+ 	/* Vortex86MX */
diff --git a/patches/arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch b/patches/arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch
new file mode 100644
index 0000000..e002005
--- /dev/null
+++ b/patches/arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch
@@ -0,0 +1,52 @@
+From 54c09889bff6d99c8733eed4a26c9391b177c88b Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 12 Oct 2015 15:46:08 +0200
+Subject: ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode
+
+commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream.
+
+The z2 machine calls pxa27x_set_pwrmode() in order to power off
+the machine, but this function gets discarded early at boot because
+it is marked __init, as pointed out by kbuild:
+
+WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode()
+The function z2_power_off() references
+the function __init pxa27x_set_pwrmode().
+This is often because z2_power_off lacks a __init
+annotation or the annotation of pxa27x_set_pwrmode is wrong.
+
+This removes the __init section modifier to fix rebooting and the
+build error.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available")
+Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
+[lizf: Backported to 3.4: adjust context]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ arch/arm/mach-pxa/include/mach/pxa27x.h |    2 +-
+ arch/arm/mach-pxa/pxa27x.c              |    2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/mach-pxa/include/mach/pxa27x.h
++++ b/arch/arm/mach-pxa/include/mach/pxa27x.h
+@@ -21,7 +21,7 @@
+ 
+ extern void __init pxa27x_map_io(void);
+ extern void __init pxa27x_init_irq(void);
+-extern int __init pxa27x_set_pwrmode(unsigned int mode);
++extern int pxa27x_set_pwrmode(unsigned int mode);
+ extern void pxa27x_cpu_pm_enter(suspend_state_t state);
+ 
+ #define pxa27x_handle_irq	ichp_handle_irq
+--- a/arch/arm/mach-pxa/pxa27x.c
++++ b/arch/arm/mach-pxa/pxa27x.c
+@@ -242,7 +242,7 @@ static struct clk_lookup pxa27x_clkregs[
+  */
+ static unsigned int pwrmode = PWRMODE_SLEEP;
+ 
+-int __init pxa27x_set_pwrmode(unsigned int mode)
++int pxa27x_set_pwrmode(unsigned int mode)
+ {
+ 	switch (mode) {
+ 	case PWRMODE_SLEEP:
diff --git a/patches/binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch b/patches/binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch
new file mode 100644
index 0000000..3f7ca21
--- /dev/null
+++ b/patches/binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch
@@ -0,0 +1,59 @@
+From b582ef5c53040c5feef4c96a8f9585b6831e2441 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@imgtec.com>
+Date: Mon, 26 Oct 2015 15:48:19 +0000
+Subject: binfmt_elf: Don't clobber passed executable's file header
+
+commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream.
+
+Do not clobber the buffer space passed from `search_binary_handler' and
+originally preloaded by `prepare_binprm' with the executable's file
+header by overwriting it with its interpreter's file header.  Instead
+keep the buffer space intact and directly use the data structure locally
+allocated for the interpreter's file header, fixing a bug introduced in
+2.1.14 with loadable module support (linux-mips.org commit beb11695
+[Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
+Adjust the amount of data read from the interpreter's file accordingly.
+
+This was not an issue before loadable module support, because back then
+`load_elf_binary' was executed only once for a given ELF executable,
+whether the function succeeded or failed.
+
+With loadable module support supported and enabled, upon a failure of
+`load_elf_binary' -- which may for example be caused by architecture
+code rejecting an executable due to a missing hardware feature requested
+in the file header -- a module load is attempted and then the function
+reexecuted by `search_binary_handler'.  With the executable's file
+header replaced with its interpreter's file header the executable can
+then be erroneously accepted in this subsequent attempt.
+
+Signed-off-by: Maciej W. Rozycki <macro@imgtec.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ fs/binfmt_elf.c |   10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/binfmt_elf.c
++++ b/fs/binfmt_elf.c
+@@ -668,16 +668,16 @@ static int load_elf_binary(struct linux_
+ 			 */
+ 			would_dump(bprm, interpreter);
+ 
+-			retval = kernel_read(interpreter, 0, bprm->buf,
+-					     BINPRM_BUF_SIZE);
+-			if (retval != BINPRM_BUF_SIZE) {
++			/* Get the exec headers */
++			retval = kernel_read(interpreter, 0,
++					     (void *)&loc->interp_elf_ex,
++					     sizeof(loc->interp_elf_ex));
++			if (retval != sizeof(loc->interp_elf_ex)) {
+ 				if (retval >= 0)
+ 					retval = -EIO;
+ 				goto out_free_dentry;
+ 			}
+ 
+-			/* Get the exec headers */
+-			loc->interp_elf_ex = *((struct elfhdr *)bprm->buf);
+ 			break;
+ 		}
+ 		elf_ppnt++;
diff --git a/patches/bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch b/patches/bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch
new file mode 100644
index 0000000..37ac757
--- /dev/null
+++ b/patches/bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch
@@ -0,0 +1,52 @@
+From 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 Mon Sep 17 00:00:00 2001
+From: Dmitry Tunin <hanipouspilot@gmail.com>
+Date: Fri, 16 Oct 2015 11:45:26 +0300
+Subject: Bluetooth: ath3k: Add support of AR3012 0cf3:817b device
+
+commit 18e0afab8ce3f1230ce3fef52b2e73374fd9c0e7 upstream.
+
+T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
+D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
+P: Vendor=0cf3 ProdID=817b Rev=00.02
+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
+I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
+
+BugLink: https://bugs.launchpad.net/bugs/1506615
+
+Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/bluetooth/ath3k.c |    2 ++
+ drivers/bluetooth/btusb.c |    1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/drivers/bluetooth/ath3k.c
++++ b/drivers/bluetooth/ath3k.c
+@@ -94,6 +94,7 @@ static struct usb_device_id ath3k_table[
+ 	{ USB_DEVICE(0x0CF3, 0x311D) },
+ 	{ USB_DEVICE(0x0cf3, 0x3121) },
+ 	{ USB_DEVICE(0x0CF3, 0x817a) },
++	{ USB_DEVICE(0x0CF3, 0x817b) },
+ 	{ USB_DEVICE(0x0cf3, 0xe003) },
+ 	{ USB_DEVICE(0x0CF3, 0xE004) },
+ 	{ USB_DEVICE(0x0CF3, 0xE005) },
+@@ -144,6 +145,7 @@ static struct usb_device_id ath3k_blist_
+ 	{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0CF3, 0x817a), .driver_info = BTUSB_ATH3012 },
++	{ USB_DEVICE(0x0CF3, 0x817b), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+--- a/drivers/bluetooth/btusb.c
++++ b/drivers/bluetooth/btusb.c
+@@ -172,6 +172,7 @@ static struct usb_device_id blacklist_ta
+ 	{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0x817a), .driver_info = BTUSB_ATH3012 },
++	{ USB_DEVICE(0x0cf3, 0x817b), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ 	{ USB_DEVICE(0x0cf3, 0xe005), .driver_info = BTUSB_ATH3012 },
diff --git a/patches/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch b/patches/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch
new file mode 100644
index 0000000..7a828c0
--- /dev/null
+++ b/patches/btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch
@@ -0,0 +1,119 @@
+From 1d512cb77bdbda80f0dd0620a3b260d697fd581d Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Mon, 9 Nov 2015 00:33:58 +0000
+Subject: Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow
+
+commit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream.
+
+If we are using the NO_HOLES feature, we have a tiny time window when
+running delalloc for a nodatacow inode where we can race with a concurrent
+link or xattr add operation leading to a BUG_ON.
+
+This happens because at run_delalloc_nocow() we end up casting a leaf item
+of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a
+file extent item (struct btrfs_file_extent_item) and then analyse its
+extent type field, which won't match any of the expected extent types
+(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an
+explicit BUG_ON(1).
+
+The following sequence diagram shows how the race happens when running a
+no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following
+neighbour leafs:
+
+             Leaf X (has N items)                    Leaf Y
+
+ [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
+              slot N - 2         slot N - 1              slot 0
+
+ (Note the implicit hole for inode 257 regarding the [0, 8K[ range)
+
+       CPU 1                                         CPU 2
+
+ run_dealloc_nocow()
+   btrfs_lookup_file_extent()
+     --> searches for a key with value
+         (257 EXTENT_DATA 4096) in the
+         fs/subvol tree
+     --> returns us a path with
+         path->nodes[0] == leaf X and
+         path->slots[0] == N
+
+   because path->slots[0] is >=
+   btrfs_header_nritems(leaf X), it
+   calls btrfs_next_leaf()
+
+   btrfs_next_leaf()
+     --> releases the path
+
+                                              hard link added to our inode,
+                                              with key (257 INODE_REF 500)
+                                              added to the end of leaf X,
+                                              so leaf X now has N + 1 keys
+
+     --> searches for the key
+         (257 INODE_REF 256), because
+         it was the last key in leaf X
+         before it released the path,
+         with path->keep_locks set to 1
+
+     --> ends up at leaf X again and
+         it verifies that the key
+         (257 INODE_REF 256) is no longer
+         the last key in the leaf, so it
+         returns with path->nodes[0] ==
+         leaf X and path->slots[0] == N,
+         pointing to the new item with
+         key (257 INODE_REF 500)
+
+   the loop iteration of run_dealloc_nocow()
+   does not break out the loop and continues
+   because the key referenced in the path
+   at path->nodes[0] and path->slots[0] is
+   for inode 257, its type is < BTRFS_EXTENT_DATA_KEY
+   and its offset (500) is less then our delalloc
+   range's end (8192)
+
+   the item pointed by the path, an inode reference item,
+   is (incorrectly) interpreted as a file extent item and
+   we get an invalid extent type, leading to the BUG_ON(1):
+
+   if (extent_type == BTRFS_FILE_EXTENT_REG ||
+      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
+       (...)
+   } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
+       (...)
+   } else {
+       BUG_ON(1)
+   }
+
+The same can happen if a xattr is added concurrently and ends up having
+a key with an offset smaller then the delalloc's range end.
+
+So fix this by skipping keys with a type smaller than
+BTRFS_EXTENT_DATA_KEY.
+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ fs/btrfs/inode.c |   10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -1203,8 +1203,14 @@ next_slot:
+ 		num_bytes = 0;
+ 		btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
+ 
+-		if (found_key.objectid > ino ||
+-		    found_key.type > BTRFS_EXTENT_DATA_KEY ||
++		if (found_key.objectid > ino)
++			break;
++		if (WARN_ON_ONCE(found_key.objectid < ino) ||
++		    found_key.type < BTRFS_EXTENT_DATA_KEY) {
++			path->slots[0]++;
++			goto next_slot;
++		}
++		if (found_key.type > BTRFS_EXTENT_DATA_KEY ||
+ 		    found_key.offset > end)
+ 			break;
+ 
diff --git a/patches/crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch b/patches/crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch
new file mode 100644
index 0000000..115ef04
--- /dev/null
+++ b/patches/crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch
@@ -0,0 +1,51 @@
+From 4afa5f9617927453ac04b24b584f6c718dfb4f45 Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Sun, 1 Nov 2015 17:11:19 +0800
+Subject: crypto: algif_hash - Only export and import on sockets with data
+
+commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream.
+
+The hash_accept call fails to work on sockets that have not received
+any data.  For some algorithm implementations it may cause crashes.
+
+This patch fixes this by ensuring that we only export and import on
+sockets that have received data.
+
+Reported-by: Harsh Jain <harshjain.prof@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Tested-by: Stephan Mueller <smueller@chronox.de>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ crypto/algif_hash.c |   12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/crypto/algif_hash.c
++++ b/crypto/algif_hash.c
+@@ -192,9 +192,14 @@ static int hash_accept(struct socket *so
+ 	struct sock *sk2;
+ 	struct alg_sock *ask2;
+ 	struct hash_ctx *ctx2;
++	bool more;
+ 	int err;
+ 
+-	err = crypto_ahash_export(req, state);
++	lock_sock(sk);
++	more = ctx->more;
++	err = more ? crypto_ahash_export(req, state) : 0;
++	release_sock(sk);
++
+ 	if (err)
+ 		return err;
+ 
+@@ -205,7 +210,10 @@ static int hash_accept(struct socket *so
+ 	sk2 = newsock->sk;
+ 	ask2 = alg_sk(sk2);
+ 	ctx2 = ask2->private;
+-	ctx2->more = 1;
++	ctx2->more = more;
++
++	if (!more)
++		return err;
+ 
+ 	err = crypto_ahash_import(&ctx2->req, state);
+ 	if (err) {
diff --git a/patches/devres-fix-a-for-loop-bounds-check.patch b/patches/devres-fix-a-for-loop-bounds-check.patch
new file mode 100644
index 0000000..1249426
--- /dev/null
+++ b/patches/devres-fix-a-for-loop-bounds-check.patch
@@ -0,0 +1,32 @@
+From 1f35d04a02a652f14566f875aef3a6f2af4cb77b Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Mon, 21 Sep 2015 19:21:51 +0300
+Subject: devres: fix a for loop bounds check
+
+commit 1f35d04a02a652f14566f875aef3a6f2af4cb77b upstream.
+
+The iomap[] array has PCIM_IOMAP_MAX (6) elements and not
+DEVICE_COUNT_RESOURCE (16).  This bug was found using a static checker.
+It may be that the "if (!(mask & (1 << i)))" check means we never
+actually go past the end of the array in real life.
+
+Fixes: ec04b075843d ('iomap: implement pcim_iounmap_regions()')
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ lib/devres.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/lib/devres.c
++++ b/lib/devres.c
+@@ -390,7 +390,7 @@ void pcim_iounmap_regions(struct pci_dev
+ 	if (!iomap)
+ 		return;
+ 
+-	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
++	for (i = 0; i < PCIM_IOMAP_MAX; i++) {
+ 		if (!(mask & (1 << i)))
+ 			continue;
+ 
diff --git a/patches/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch b/patches/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch
new file mode 100644
index 0000000..a74e81a
--- /dev/null
+++ b/patches/ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch
@@ -0,0 +1,102 @@
+From 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 Mon Sep 17 00:00:00 2001
+From: Daeho Jeong <daeho.jeong@samsung.com>
+Date: Sun, 18 Oct 2015 17:02:56 -0400
+Subject: ext4, jbd2: ensure entering into panic after recording an error in
+ superblock
+
+commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.
+
+If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
+journaling will be aborted first and the error number will be recorded
+into JBD2 superblock and, finally, the system will enter into the
+panic state in "errors=panic" option.  But, in the rare case, this
+sequence is little twisted like the below figure and it will happen
+that the system enters into panic state, which means the system reset
+in mobile environment, before completion of recording an error in the
+journal superblock. In this case, e2fsck cannot recognize that the
+filesystem failure occurred in the previous run and the corruption
+wouldn't be fixed.
+
+Task A                        Task B
+ext4_handle_error()
+-> jbd2_journal_abort()
+  -> __journal_abort_soft()
+    -> __jbd2_journal_abort_hard()
+    | -> journal->j_flags |= JBD2_ABORT;
+    |
+    |                         __ext4_abort()
+    |                         -> jbd2_journal_abort()
+    |                         | -> __journal_abort_soft()
+    |                         |   -> if (journal->j_flags & JBD2_ABORT)
+    |                         |           return;
+    |                         -> panic()
+    |
+    -> jbd2_journal_update_sb_errno()
+
+Tested-by: Hobin Woo <hobin.woo@samsung.com>
+Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ fs/ext4/super.c      |   12 ++++++++++--
+ fs/jbd2/journal.c    |    6 +++++-
+ include/linux/jbd2.h |    1 +
+ 3 files changed, 16 insertions(+), 3 deletions(-)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -483,9 +483,13 @@ static void ext4_handle_error(struct sup
+ 		ext4_msg(sb, KERN_CRIT, "Remounting filesystem read-only");
+ 		sb->s_flags |= MS_RDONLY;
+ 	}
+-	if (test_opt(sb, ERRORS_PANIC))
++	if (test_opt(sb, ERRORS_PANIC)) {
++		if (EXT4_SB(sb)->s_journal &&
++		  !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
++			return;
+ 		panic("EXT4-fs (device %s): panic forced after error\n",
+ 			sb->s_id);
++	}
+ }
+ 
+ void __ext4_error(struct super_block *sb, const char *function,
+@@ -659,8 +663,12 @@ void __ext4_abort(struct super_block *sb
+ 			jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO);
+ 		save_error_info(sb, function, line);
+ 	}
+-	if (test_opt(sb, ERRORS_PANIC))
++	if (test_opt(sb, ERRORS_PANIC)) {
++		if (EXT4_SB(sb)->s_journal &&
++		  !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
++			return;
+ 		panic("EXT4-fs panic from previous error\n");
++	}
+ }
+ 
+ void ext4_msg(struct super_block *sb, const char *prefix, const char *fmt, ...)
+--- a/fs/jbd2/journal.c
++++ b/fs/jbd2/journal.c
+@@ -1921,8 +1921,12 @@ static void __journal_abort_soft (journa
+ 
+ 	__jbd2_journal_abort_hard(journal);
+ 
+-	if (errno)
++	if (errno) {
+ 		jbd2_journal_update_sb_errno(journal);
++		write_lock(&journal->j_state_lock);
++		journal->j_flags |= JBD2_REC_ERR;
++		write_unlock(&journal->j_state_lock);
++	}
+ }
+ 
+ /**
+--- a/include/linux/jbd2.h
++++ b/include/linux/jbd2.h
+@@ -954,6 +954,7 @@ struct journal_s
+ #define JBD2_ABORT_ON_SYNCDATA_ERR	0x040	/* Abort the journal on file
+ 						 * data write error in ordered
+ 						 * mode */
++#define JBD2_REC_ERR	0x080	/* The errno in the sb has been recorded */
+ 
+ /*
+  * Function declarations for the journaling transaction and buffer
diff --git a/patches/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch b/patches/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch
new file mode 100644
index 0000000..df8fdb3
--- /dev/null
+++ b/patches/firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch
@@ -0,0 +1,68 @@
+From 100ceb66d5c40cc0c7018e06a9474302470be73c Mon Sep 17 00:00:00 2001
+From: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Date: Tue, 3 Nov 2015 01:46:21 +0100
+Subject: firewire: ohci: fix JMicron JMB38x IT context discovery
+
+commit 100ceb66d5c40cc0c7018e06a9474302470be73c upstream.
+
+Reported by Clifford and Craig for JMicron OHCI-1394 + SDHCI combo
+controllers:  Often or even most of the time, the controller is
+initialized with the message "added OHCI v1.10 device as card 0, 4 IR +
+0 IT contexts, quirks 0x10".  With 0 isochronous transmit DMA contexts
+(IT contexts), applications like audio output are impossible.
+
+However, OHCI-1394 demands that at least 4 IT contexts are implemented
+by the link layer controller, and indeed JMicron JMB38x do implement
+four of them.  Only their IsoXmitIntMask register is unreliable at early
+access.
+
+With my own JMB381 single function controller I found:
+  - I can reproduce the problem with a lower probability than Craig's.
+  - If I put a loop around the section which clears and reads
+    IsoXmitIntMask, then either the first or the second attempt will
+    return the correct initial mask of 0x0000000f.  I never encountered
+    a case of needing more than a second attempt.
+  - Consequently, if I put a dummy reg_read(...IsoXmitIntMaskSet)
+    before the first write, the subsequent read will return the correct
+    result.
+  - If I merely ignore a wrong read result and force the known real
+    result, later isochronous transmit DMA usage works just fine.
+
+So let's just fix this chip bug up by the latter method.  Tested with
+JMB381 on kernel 3.13 and 4.3.
+
+Since OHCI-1394 generally requires 4 IT contexts at a minium, this
+workaround is simply applied whenever the initial read of IsoXmitIntMask
+returns 0, regardless whether it's a JMicron chip or not.  I never heard
+of this issue together with any other chip though.
+
+I am not 100% sure that this fix works on the OHCI-1394 part of JMB380
+and JMB388 combo controllers exactly the same as on the JMB381 single-
+function controller, but so far I haven't had a chance to let an owner
+of a combo chip run a patched kernel.
+
+Strangely enough, IsoRecvIntMask is always reported correctly, even
+though it is probed right before IsoXmitIntMask.
+
+Reported-by: Clifford Dunn
+Reported-by: Craig Moore <craig.moore@qenos.com>
+Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/firewire/ohci.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/firewire/ohci.c
++++ b/drivers/firewire/ohci.c
+@@ -3620,6 +3620,11 @@ static int __devinit pci_probe(struct pc
+ 
+ 	reg_write(ohci, OHCI1394_IsoXmitIntMaskSet, ~0);
+ 	ohci->it_context_support = reg_read(ohci, OHCI1394_IsoXmitIntMaskSet);
++	/* JMicron JMB38x often shows 0 at first read, just ignore it */
++	if (!ohci->it_context_support) {
++		ohci_notice(ohci, "overriding IsoXmitIntMask\n");
++		ohci->it_context_support = 0xf;
++	}
+ 	reg_write(ohci, OHCI1394_IsoXmitIntMaskClear, ~0);
+ 	ohci->it_context_mask = ohci->it_context_support;
+ 	ohci->n_it = hweight32(ohci->it_context_mask);
diff --git a/patches/fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch b/patches/fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch
new file mode 100644
index 0000000..93df0dc
--- /dev/null
+++ b/patches/fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch
@@ -0,0 +1,88 @@
+From b130ed5998e62879a66bad08931a2b5e832da95c Mon Sep 17 00:00:00 2001
+From: Kinglong Mee <kinglongmee@gmail.com>
+Date: Wed, 4 Nov 2015 15:20:24 +0000
+Subject: FS-Cache: Don't override netfs's primary_index if registering failed
+
+commit b130ed5998e62879a66bad08931a2b5e832da95c upstream.
+
+Only override netfs->primary_index when registering success.
+
+Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+[lizf: Backported to 3.4: there are no n_active and flags in primary_index]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ fs/fscache/netfs.c |   31 +++++++++++++++----------------
+ 1 file changed, 15 insertions(+), 16 deletions(-)
+
+--- a/fs/fscache/netfs.c
++++ b/fs/fscache/netfs.c
+@@ -22,6 +22,7 @@ static LIST_HEAD(fscache_netfs_list);
+ int __fscache_register_netfs(struct fscache_netfs *netfs)
+ {
+ 	struct fscache_netfs *ptr;
++	struct fscache_cookie *cookie;
+ 	int ret;
+ 
+ 	_enter("{%s}", netfs->name);
+@@ -29,24 +30,23 @@ int __fscache_register_netfs(struct fsca
+ 	INIT_LIST_HEAD(&netfs->link);
+ 
+ 	/* allocate a cookie for the primary index */
+-	netfs->primary_index =
+-		kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL);
++	cookie = kmem_cache_zalloc(fscache_cookie_jar, GFP_KERNEL);
+ 
+-	if (!netfs->primary_index) {
++	if (!cookie) {
+ 		_leave(" = -ENOMEM");
+ 		return -ENOMEM;
+ 	}
+ 
+ 	/* initialise the primary index cookie */
+-	atomic_set(&netfs->primary_index->usage, 1);
+-	atomic_set(&netfs->primary_index->n_children, 0);
++	atomic_set(&cookie->usage, 1);
++	atomic_set(&cookie->n_children, 0);
+ 
+-	netfs->primary_index->def		= &fscache_fsdef_netfs_def;
+-	netfs->primary_index->parent		= &fscache_fsdef_index;
+-	netfs->primary_index->netfs_data	= netfs;
++	cookie->def		= &fscache_fsdef_netfs_def;
++	cookie->parent		= &fscache_fsdef_index;
++	cookie->netfs_data	= netfs;
+ 
+-	spin_lock_init(&netfs->primary_index->lock);
+-	INIT_HLIST_HEAD(&netfs->primary_index->backing_objects);
++	spin_lock_init(&cookie->lock);
++	INIT_HLIST_HEAD(&cookie->backing_objects);
+ 
+ 	/* check the netfs type is not already present */
+ 	down_write(&fscache_addremove_sem);
+@@ -57,9 +57,10 @@ int __fscache_register_netfs(struct fsca
+ 			goto already_registered;
+ 	}
+ 
+-	atomic_inc(&netfs->primary_index->parent->usage);
+-	atomic_inc(&netfs->primary_index->parent->n_children);
++	atomic_inc(&cookie->parent->usage);
++	atomic_inc(&cookie->parent->n_children);
+ 
++	netfs->primary_index = cookie;
+ 	list_add(&netfs->link, &fscache_netfs_list);
+ 	ret = 0;
+ 
+@@ -69,10 +70,8 @@ int __fscache_register_netfs(struct fsca
+ already_registered:
+ 	up_write(&fscache_addremove_sem);
+ 
+-	if (ret < 0) {
+-		kmem_cache_free(fscache_cookie_jar, netfs->primary_index);
+-		netfs->primary_index = NULL;
+-	}
++	if (ret < 0)
++		kmem_cache_free(fscache_cookie_jar, cookie);
+ 
+ 	_leave(" = %d", ret);
+ 	return ret;
diff --git a/patches/fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch b/patches/fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch
new file mode 100644
index 0000000..b5cfb48
--- /dev/null
+++ b/patches/fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch
@@ -0,0 +1,154 @@
+From 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 4 Nov 2015 15:20:42 +0000
+Subject: FS-Cache: Handle a write to the page immediately beyond the EOF
+ marker
+
+commit 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 upstream.
+
+Handle a write being requested to the page immediately beyond the EOF
+marker on a cache object.  Currently this gets an assertion failure in
+CacheFiles because the EOF marker is used there to encode information about
+a partial page at the EOF - which could lead to an unknown blank spot in
+the file if we extend the file over it.
+
+The problem is actually in fscache where we check the index of the page
+being written against store_limit.  store_limit is set to the number of
+pages that we're allowed to store by fscache_set_store_limit() - which
+means it's one more than the index of the last page we're allowed to store.
+The problem is that we permit writing to a page with an index _equal_ to
+the store limit - when we should reject that case.
+
+Whilst we're at it, change the triggered assertion in CacheFiles to just
+return -ENOBUFS instead.
+
+The assertion failure looks something like this:
+
+CacheFiles: Assertion failed
+1000 < 7b1 is false
+------------[ cut here ]------------
+kernel BUG at fs/cachefiles/rdwr.c:962!
+...
+RIP: 0010:[<ffffffffa02c9e83>]  [<ffffffffa02c9e83>] cachefiles_write_page+0x273/0x2d0 [cachefiles]
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+[lizf: Backported to 3.4: adjust context]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ fs/cachefiles/rdwr.c |   80 ++++++++++++++++++++++++++++-----------------------
+ fs/fscache/page.c    |    2 -
+ 2 files changed, 45 insertions(+), 37 deletions(-)
+
+--- a/fs/cachefiles/rdwr.c
++++ b/fs/cachefiles/rdwr.c
+@@ -914,6 +914,15 @@ int cachefiles_write_page(struct fscache
+ 	cache = container_of(object->fscache.cache,
+ 			     struct cachefiles_cache, cache);
+ 
++	pos = (loff_t)page->index << PAGE_SHIFT;
++
++	/* We mustn't write more data than we have, so we have to beware of a
++	 * partial page at EOF.
++	 */
++	eof = object->fscache.store_limit_l;
++	if (pos >= eof)
++		goto error;
++
+ 	/* write the page to the backing filesystem and let it store it in its
+ 	 * own time */
+ 	dget(object->backer);
+@@ -922,47 +931,46 @@ int cachefiles_write_page(struct fscache
+ 			   cache->cache_cred);
+ 	if (IS_ERR(file)) {
+ 		ret = PTR_ERR(file);
+-	} else {
++		goto error_2;
++	}
++	if (!file->f_op->write) {
+ 		ret = -EIO;
+-		if (file->f_op->write) {
+-			pos = (loff_t) page->index << PAGE_SHIFT;
+-
+-			/* we mustn't write more data than we have, so we have
+-			 * to beware of a partial page at EOF */
+-			eof = object->fscache.store_limit_l;
+-			len = PAGE_SIZE;
+-			if (eof & ~PAGE_MASK) {
+-				ASSERTCMP(pos, <, eof);
+-				if (eof - pos < PAGE_SIZE) {
+-					_debug("cut short %llx to %llx",
+-					       pos, eof);
+-					len = eof - pos;
+-					ASSERTCMP(pos + len, ==, eof);
+-				}
+-			}
+-
+-			data = kmap(page);
+-			old_fs = get_fs();
+-			set_fs(KERNEL_DS);
+-			ret = file->f_op->write(
+-				file, (const void __user *) data, len, &pos);
+-			set_fs(old_fs);
+-			kunmap(page);
+-			if (ret != len)
+-				ret = -EIO;
+-		}
+-		fput(file);
++		goto error_2;
+ 	}
+ 
+-	if (ret < 0) {
+-		if (ret == -EIO)
+-			cachefiles_io_error_obj(
+-				object, "Write page to backing file failed");
+-		ret = -ENOBUFS;
++	len = PAGE_SIZE;
++	if (eof & ~PAGE_MASK) {
++		if (eof - pos < PAGE_SIZE) {
++			_debug("cut short %llx to %llx",
++			       pos, eof);
++			len = eof - pos;
++			ASSERTCMP(pos + len, ==, eof);
++		}
+ 	}
+ 
+-	_leave(" = %d", ret);
+-	return ret;
++	data = kmap(page);
++	old_fs = get_fs();
++	set_fs(KERNEL_DS);
++	ret = file->f_op->write(
++		file, (const void __user *) data, len, &pos);
++	set_fs(old_fs);
++	kunmap(page);
++	fput(file);
++	if (ret != len)
++		goto error_eio;
++
++	_leave(" = 0");
++	return 0;
++
++error_eio:
++	ret = -EIO;
++error_2:
++	if (ret == -EIO)
++		cachefiles_io_error_obj(object,
++					"Write page to backing file failed");
++error:
++	_leave(" = -ENOBUFS [%d]", ret);
++	return -ENOBUFS;
+ }
+ 
+ /*
+--- a/fs/fscache/page.c
++++ b/fs/fscache/page.c
+@@ -676,7 +676,7 @@ static void fscache_write_op(struct fsca
+ 		goto superseded;
+ 	page = results[0];
+ 	_debug("gang %d [%lx]", n, page->index);
+-	if (page->index > op->store_limit) {
++	if (page->index >= op->store_limit) {
+ 		fscache_stat(&fscache_n_store_pages_over_limit);
+ 		goto superseded;
+ 	}
diff --git a/patches/fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch b/patches/fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch
new file mode 100644
index 0000000..6cee7e4
--- /dev/null
+++ b/patches/fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch
@@ -0,0 +1,57 @@
+From 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 Mon Sep 17 00:00:00 2001
+From: Kinglong Mee <kinglongmee@gmail.com>
+Date: Wed, 4 Nov 2015 15:20:15 +0000
+Subject: FS-Cache: Increase reference of parent after registering, netfs
+ success
+
+commit 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 upstream.
+
+If netfs exist, fscache should not increase the reference of parent's
+usage and n_children, otherwise, never be decreased.
+
+v2: thanks David's suggest,
+ move increasing reference of parent if success
+ use kmem_cache_free() freeing primary_index directly
+
+v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;"
+
+Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ fs/fscache/netfs.c |    9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/fs/fscache/netfs.c
++++ b/fs/fscache/netfs.c
+@@ -45,9 +45,6 @@ int __fscache_register_netfs(struct fsca
+ 	netfs->primary_index->parent		= &fscache_fsdef_index;
+ 	netfs->primary_index->netfs_data	= netfs;
+ 
+-	atomic_inc(&netfs->primary_index->parent->usage);
+-	atomic_inc(&netfs->primary_index->parent->n_children);
+-
+ 	spin_lock_init(&netfs->primary_index->lock);
+ 	INIT_HLIST_HEAD(&netfs->primary_index->backing_objects);
+ 
+@@ -60,6 +57,9 @@ int __fscache_register_netfs(struct fsca
+ 			goto already_registered;
+ 	}
+ 
++	atomic_inc(&netfs->primary_index->parent->usage);
++	atomic_inc(&netfs->primary_index->parent->n_children);
++
+ 	list_add(&netfs->link, &fscache_netfs_list);
+ 	ret = 0;
+ 
+@@ -70,8 +70,7 @@ already_registered:
+ 	up_write(&fscache_addremove_sem);
+ 
+ 	if (ret < 0) {
+-		netfs->primary_index->parent = NULL;
+-		__fscache_cookie_put(netfs->primary_index);
++		kmem_cache_free(fscache_cookie_jar, netfs->primary_index);
+ 		netfs->primary_index = NULL;
+ 	}
+ 
diff --git a/patches/hid-core-avoid-uninitialized-buffer-access.patch b/patches/hid-core-avoid-uninitialized-buffer-access.patch
new file mode 100644
index 0000000..efee385
--- /dev/null
+++ b/patches/hid-core-avoid-uninitialized-buffer-access.patch
@@ -0,0 +1,36 @@
+From 79b568b9d0c7c5d81932f4486d50b38efdd6da6d Mon Sep 17 00:00:00 2001
+From: Richard Purdie <richard.purdie@linuxfoundation.org>
+Date: Fri, 18 Sep 2015 16:31:33 -0700
+Subject: HID: core: Avoid uninitialized buffer access
+
+commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.
+
+hid_connect adds various strings to the buffer but they're all
+conditional. You can find circumstances where nothing would be written
+to it but the kernel will still print the supposedly empty buffer with
+printk. This leads to corruption on the console/in the logs.
+
+Ensure buf is initialized to an empty string.
+
+Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
+[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
+Cc: Jiri Kosina <jikos@kernel.org>
+Cc: linux-input@vger.kernel.org
+Signed-off-by: Darren Hart <dvhart@linux.intel.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/hid/hid-core.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hid/hid-core.c
++++ b/drivers/hid/hid-core.c
+@@ -1301,7 +1301,7 @@ int hid_connect(struct hid_device *hdev,
+ 		"Multi-Axis Controller"
+ 	};
+ 	const char *type, *bus;
+-	char buf[64];
++	char buf[64] = "";
+ 	unsigned int i;
+ 	int len;
+ 	int ret;
diff --git a/patches/iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch b/patches/iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch
new file mode 100644
index 0000000..9f7750b
--- /dev/null
+++ b/patches/iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch
@@ -0,0 +1,34 @@
+From d14053b3c714178525f22660e6aaf41263d00056 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <David.Woodhouse@intel.com>
+Date: Thu, 15 Oct 2015 09:28:06 +0100
+Subject: iommu/vt-d: Fix ATSR handling for Root-Complex integrated endpoints
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+commit d14053b3c714178525f22660e6aaf41263d00056 upstream.
+
+The VT-d specification says that "Software must enable ATS on endpoint
+devices behind a Root Port only if the Root Port is reported as
+supporting ATS transactions."
+
+We walk up the tree to find a Root Port, but for integrated devices we
+don't find one — we get to the host bridge. In that case we *should*
+allow ATS. Currently we don't, which means that we are incorrectly
+failing to use ATS for the integrated graphics. Fix that.
+
+We should never break out of this loop "naturally" with bus==NULL,
+since we'll always find bridge==NULL in that case (and now return 1).
+
+So remove the check for (!bridge) after the loop, since it can never
+happen. If it did, it would be worthy of a BUG_ON(!bridge). But since
+it'll oops anyway in that case, that'll do just as well.
+
+Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
+[lizf: Backported to 3.4:
+ - adjust context
+ - drop the last part of the changes of the patch]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ 0 files changed
+
diff --git a/patches/ipv6-fix-tunnel-error-handling.patch b/patches/ipv6-fix-tunnel-error-handling.patch
new file mode 100644
index 0000000..ad96b65
--- /dev/null
+++ b/patches/ipv6-fix-tunnel-error-handling.patch
@@ -0,0 +1,49 @@
+From ebac62fe3d24c0ce22dd83afa7b07d1a2aaef44d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michal=20Kube=C4=8Dek?= <mkubecek@suse.cz>
+Date: Tue, 3 Nov 2015 08:51:07 +0100
+Subject: ipv6: fix tunnel error handling
+
+commit ebac62fe3d24c0ce22dd83afa7b07d1a2aaef44d upstream.
+
+Both tunnel6_protocol and tunnel46_protocol share the same error
+handler, tunnel6_err(), which traverses through tunnel6_handlers list.
+For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g.
+in tunnel46_rcv(). Current code can generate an ICMPv6 error message
+with an IPv4 packet embedded in it.
+
+Fixes: 73d605d1abbd ("[IPSEC]: changing API of xfrm6_tunnel_register")
+Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ net/ipv6/tunnel6.c |   12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/net/ipv6/tunnel6.c
++++ b/net/ipv6/tunnel6.c
+@@ -145,6 +145,16 @@ static void tunnel6_err(struct sk_buff *
+ 			break;
+ }
+ 
++static void tunnel46_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
++			 u8 type, u8 code, int offset, __be32 info)
++{
++	struct xfrm6_tunnel *handler;
++
++	for_each_tunnel_rcu(tunnel46_handlers, handler)
++		if (!handler->err_handler(skb, opt, type, code, offset, info))
++			break;
++}
++
+ static const struct inet6_protocol tunnel6_protocol = {
+ 	.handler	= tunnel6_rcv,
+ 	.err_handler	= tunnel6_err,
+@@ -153,7 +163,7 @@ static const struct inet6_protocol tunne
+ 
+ static const struct inet6_protocol tunnel46_protocol = {
+ 	.handler	= tunnel46_rcv,
+-	.err_handler	= tunnel6_err,
++	.err_handler	= tunnel46_err,
+ 	.flags          = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL,
+ };
+ 
diff --git a/patches/mac80211-fix-driver-rssi-event-calculations.patch b/patches/mac80211-fix-driver-rssi-event-calculations.patch
new file mode 100644
index 0000000..d74db08
--- /dev/null
+++ b/patches/mac80211-fix-driver-rssi-event-calculations.patch
@@ -0,0 +1,30 @@
+From 8ec6d97871f37e4743678ea4a455bd59580aa0f4 Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Fri, 28 Aug 2015 10:52:53 +0200
+Subject: mac80211: fix driver RSSI event calculations
+
+commit 8ec6d97871f37e4743678ea4a455bd59580aa0f4 upstream.
+
+The ifmgd->ave_beacon_signal value cannot be taken as is for
+comparisons, it must be divided by since it's represented
+like that for better accuracy of the EWMA calculations. This
+would lead to invalid driver RSSI events. Fix the used value.
+
+Fixes: 615f7b9bb1f8 ("mac80211: add driver RSSI threshold events")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ net/mac80211/mlme.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -2384,7 +2384,7 @@ static void ieee80211_rx_mgmt_beacon(str
+ 
+ 	if (ifmgd->rssi_min_thold != ifmgd->rssi_max_thold &&
+ 	    ifmgd->count_beacon_signal >= IEEE80211_SIGNAL_AVE_MIN_COUNT) {
+-		int sig = ifmgd->ave_beacon_signal;
++		int sig = ifmgd->ave_beacon_signal / 16;
+ 		int last_sig = ifmgd->last_ave_beacon_signal;
+ 
+ 		/*
diff --git a/patches/megaraid_sas-do-not-use-page_size-for-max_sectors.patch b/patches/megaraid_sas-do-not-use-page_size-for-max_sectors.patch
new file mode 100644
index 0000000..a7e3db2
--- /dev/null
+++ b/patches/megaraid_sas-do-not-use-page_size-for-max_sectors.patch
@@ -0,0 +1,45 @@
+From 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 Mon Sep 17 00:00:00 2001
+From: "sumit.saxena@avagotech.com" <sumit.saxena@avagotech.com>
+Date: Thu, 15 Oct 2015 13:40:04 +0530
+Subject: megaraid_sas: Do not use PAGE_SIZE for max_sectors
+
+commit 357ae967ad66e357f78b5cfb5ab6ca07fb4a7758 upstream.
+
+Do not use PAGE_SIZE marco to calculate max_sectors per I/O
+request. Driver code assumes PAGE_SIZE will be always 4096 which can
+lead to wrongly calculated value if PAGE_SIZE is not 4096. This issue
+was reported in Ubuntu Bugzilla Bug #1475166.
+
+Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
+Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com>
+Reviewed-by: Tomas Henzl <thenzl@redhat.com>
+Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/scsi/megaraid/megaraid_sas.h      |    2 ++
+ drivers/scsi/megaraid/megaraid_sas_base.c |    2 +-
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/megaraid/megaraid_sas.h
++++ b/drivers/scsi/megaraid/megaraid_sas.h
+@@ -300,6 +300,8 @@ enum MR_EVT_ARGS {
+ 	MR_EVT_ARGS_GENERIC,
+ };
+ 
++
++#define SGE_BUFFER_SIZE	4096
+ /*
+  * define constants for device list query options
+  */
+--- a/drivers/scsi/megaraid/megaraid_sas_base.c
++++ b/drivers/scsi/megaraid/megaraid_sas_base.c
+@@ -3582,7 +3582,7 @@ static int megasas_init_fw(struct megasa
+ 	}
+ 
+ 	instance->max_sectors_per_req = instance->max_num_sge *
+-						PAGE_SIZE / 512;
++						SGE_BUFFER_SIZE / 512;
+ 	if (tmp_sectors && (instance->max_sectors_per_req > tmp_sectors))
+ 		instance->max_sectors_per_req = tmp_sectors;
+ 
diff --git a/patches/megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch b/patches/megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch
new file mode 100644
index 0000000..a3b02ae
--- /dev/null
+++ b/patches/megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch
@@ -0,0 +1,51 @@
+From 323c4a02c631d00851d8edc4213c4d184ef83647 Mon Sep 17 00:00:00 2001
+From: "sumit.saxena@avagotech.com" <sumit.saxena@avagotech.com>
+Date: Thu, 15 Oct 2015 13:40:54 +0530
+Subject: megaraid_sas : SMAP restriction--do not access user memory from IOCTL
+ code
+
+commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.
+
+This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
+OS. Do not access user memory from kernel code. The SMAP bit restricts
+accessing user memory from kernel code.
+
+Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
+Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com>
+Reviewed-by: Tomas Henzl <thenzl@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/scsi/megaraid/megaraid_sas_base.c |   13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/megaraid/megaraid_sas_base.c
++++ b/drivers/scsi/megaraid/megaraid_sas_base.c
+@@ -5014,6 +5014,9 @@ static int megasas_mgmt_compat_ioctl_fw(
+ 	int i;
+ 	int error = 0;
+ 	compat_uptr_t ptr;
++	unsigned long local_raw_ptr;
++	u32 local_sense_off;
++	u32 local_sense_len;
+ 
+ 	if (clear_user(ioc, sizeof(*ioc)))
+ 		return -EFAULT;
+@@ -5031,9 +5034,15 @@ static int megasas_mgmt_compat_ioctl_fw(
+ 	 * sense_len is not null, so prepare the 64bit value under
+ 	 * the same condition.
+ 	 */
+-	if (ioc->sense_len) {
++	if (get_user(local_raw_ptr, ioc->frame.raw) ||
++		get_user(local_sense_off, &ioc->sense_off) ||
++		get_user(local_sense_len, &ioc->sense_len))
++		return -EFAULT;
++
++
++	if (local_sense_len) {
+ 		void __user **sense_ioc_ptr =
+-			(void __user **)(ioc->frame.raw + ioc->sense_off);
++			(void __user **)((u8*)local_raw_ptr + local_sense_off);
+ 		compat_uptr_t *sense_cioc_ptr =
+ 			(compat_uptr_t *)(cioc->frame.raw + cioc->sense_off);
+ 		if (get_user(ptr, sense_cioc_ptr) ||
diff --git a/patches/mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch b/patches/mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch
new file mode 100644
index 0000000..5ba9454
--- /dev/null
+++ b/patches/mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch
@@ -0,0 +1,27 @@
+From f25319d2cb439249a6859f53ad42ffa332b0acba Mon Sep 17 00:00:00 2001
+From: Ralf Baechle <ralf@linux-mips.org>
+Date: Fri, 16 Oct 2015 23:09:57 +0200
+Subject: MIPS: atomic: Fix comment describing atomic64_add_unless's return
+ value.
+
+commit f25319d2cb439249a6859f53ad42ffa332b0acba upstream.
+
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Fixes: f24219b4e90cf70ec4a211b17fbabc725a0ddf3c
+(cherry picked from commit f0a232cde7be18a207fd057dd79bbac8a0a45dec)
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ arch/mips/include/asm/atomic.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/include/asm/atomic.h
++++ b/arch/mips/include/asm/atomic.h
+@@ -679,7 +679,7 @@ static __inline__ long atomic64_sub_if_p
+  * @u: ...unless v is equal to u.
+  *
+  * Atomically adds @a to @v, so long as it was not @u.
+- * Returns the old value of @v.
++ * Returns true iff @v was not @u.
+  */
+ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
+ {
diff --git a/patches/mtd-mtdpart-fix-add_mtd_partitions-error-path.patch b/patches/mtd-mtdpart-fix-add_mtd_partitions-error-path.patch
new file mode 100644
index 0000000..5a35bf6
--- /dev/null
+++ b/patches/mtd-mtdpart-fix-add_mtd_partitions-error-path.patch
@@ -0,0 +1,33 @@
+From e5bae86797141e4a95e42d825f737cb36d7b8c37 Mon Sep 17 00:00:00 2001
+From: Boris BREZILLON <boris.brezillon@free-electrons.com>
+Date: Thu, 30 Jul 2015 12:18:03 +0200
+Subject: mtd: mtdpart: fix add_mtd_partitions error path
+
+commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream.
+
+If we fail to allocate a partition structure in the middle of the partition
+creation process, the already allocated partitions are never removed, which
+means they are still present in the partition list and their resources are
+never freed.
+
+Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
+Signed-off-by: Brian Norris <computersforpeace@gmail.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/mtd/mtdpart.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/mtdpart.c
++++ b/drivers/mtd/mtdpart.c
+@@ -632,8 +632,10 @@ int add_mtd_partitions(struct mtd_info *
+ 
+ 	for (i = 0; i < nbparts; i++) {
+ 		slave = allocate_partition(master, parts + i, i, cur_offset);
+-		if (IS_ERR(slave))
++		if (IS_ERR(slave)) {
++			del_mtd_partitions(master);
+ 			return PTR_ERR(slave);
++		}
+ 
+ 		mutex_lock(&mtd_partitions_mutex);
+ 		list_add(&slave->list, &mtd_partitions);
diff --git a/patches/mwifiex-fix-mwifiex_rdeeprom_read.patch b/patches/mwifiex-fix-mwifiex_rdeeprom_read.patch
new file mode 100644
index 0000000..b5183f6
--- /dev/null
+++ b/patches/mwifiex-fix-mwifiex_rdeeprom_read.patch
@@ -0,0 +1,76 @@
+From 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Mon, 21 Sep 2015 19:19:53 +0300
+Subject: mwifiex: fix mwifiex_rdeeprom_read()
+
+commit 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 upstream.
+
+There were several bugs here.
+
+1)  The done label was in the wrong place so we didn't copy any
+    information out when there was no command given.
+
+2)  We were using PAGE_SIZE as the size of the buffer instead of
+    "PAGE_SIZE - pos".
+
+3)  snprintf() returns the number of characters that would have been
+    printed if there were enough space.  If there was not enough space
+    (and we had fixed the memory corruption bug #2) then it would result
+    in an information leak when we do simple_read_from_buffer().  I've
+    changed it to use scnprintf() instead.
+
+I also removed the initialization at the start of the function, because
+I thought it made the code a little more clear.
+
+Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex driver')
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Amitkumar Karwar <akarwar@marvell.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/net/wireless/mwifiex/debugfs.c |   14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/net/wireless/mwifiex/debugfs.c
++++ b/drivers/net/wireless/mwifiex/debugfs.c
+@@ -621,7 +621,7 @@ mwifiex_rdeeprom_read(struct file *file,
+ 		(struct mwifiex_private *) file->private_data;
+ 	unsigned long addr = get_zeroed_page(GFP_KERNEL);
+ 	char *buf = (char *) addr;
+-	int pos = 0, ret = 0, i;
++	int pos, ret, i;
+ 	u8 value[MAX_EEPROM_DATA];
+ 
+ 	if (!buf)
+@@ -629,7 +629,7 @@ mwifiex_rdeeprom_read(struct file *file,
+ 
+ 	if (saved_offset == -1) {
+ 		/* No command has been given */
+-		pos += snprintf(buf, PAGE_SIZE, "0");
++		pos = snprintf(buf, PAGE_SIZE, "0");
+ 		goto done;
+ 	}
+ 
+@@ -638,17 +638,17 @@ mwifiex_rdeeprom_read(struct file *file,
+ 				  (u16) saved_bytes, value);
+ 	if (ret) {
+ 		ret = -EINVAL;
+-		goto done;
++		goto out_free;
+ 	}
+ 
+-	pos += snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
++	pos = snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
+ 
+ 	for (i = 0; i < saved_bytes; i++)
+-		pos += snprintf(buf + strlen(buf), PAGE_SIZE, "%d ", value[i]);
+-
+-	ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
++		pos += scnprintf(buf + pos, PAGE_SIZE - pos, "%d ", value[i]);
+ 
+ done:
++	ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
++out_free:
+ 	free_page(addr);
+ 	return ret;
+ }
diff --git a/patches/net-fix-a-race-in-dst_release.patch b/patches/net-fix-a-race-in-dst_release.patch
new file mode 100644
index 0000000..5269469
--- /dev/null
+++ b/patches/net-fix-a-race-in-dst_release.patch
@@ -0,0 +1,33 @@
+From d69bbf88c8d0b367cf3e3a052f6daadf630ee566 Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Mon, 9 Nov 2015 17:51:23 -0800
+Subject: net: fix a race in dst_release()
+
+commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 upstream.
+
+Only cpu seeing dst refcount going to 0 can safely
+dereference dst->flags.
+
+Otherwise an other cpu might already have freed the dst.
+
+Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
+Reported-by: Greg Thelen <gthelen@google.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+[lizf: Backported to 3.4: adjust context]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ net/core/dst.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/core/dst.c
++++ b/net/core/dst.c
+@@ -272,7 +272,7 @@ void dst_release(struct dst_entry *dst)
+ 
+ 		newrefcnt = atomic_dec_return(&dst->__refcnt);
+ 		WARN_ON(newrefcnt < 0);
+-		if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt) {
++		if (!newrefcnt && unlikely(dst->flags & DST_NOCACHE)) {
+ 			dst = dst_destroy(dst);
+ 			if (dst)
+ 				__dst_free(dst);
diff --git a/patches/perf-fix-inherited-events-vs.-tracepoint-filters.patch b/patches/perf-fix-inherited-events-vs.-tracepoint-filters.patch
new file mode 100644
index 0000000..8c34630
--- /dev/null
+++ b/patches/perf-fix-inherited-events-vs.-tracepoint-filters.patch
@@ -0,0 +1,51 @@
+From b71b437eedaed985062492565d9d421d975ae845 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Mon, 2 Nov 2015 10:50:51 +0100
+Subject: perf: Fix inherited events vs. tracepoint filters
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+commit b71b437eedaed985062492565d9d421d975ae845 upstream.
+
+Arnaldo reported that tracepoint filters seem to misbehave (ie. not
+apply) on inherited events.
+
+The fix is obvious; filters are only set on the actual (parent)
+event, use the normal pattern of using this parent event for filters.
+This is safe because each child event has a reference to it.
+
+Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
+Tested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: David Ahern <dsahern@gmail.com>
+Cc: Frédéric Weisbecker <fweisbec@gmail.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Wang Nan <wangnan0@huawei.com>
+Link: http://lkml.kernel.org/r/20151102095051.GN17308@twins.programming.kicks-ass.net
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ kernel/events/core.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -5366,6 +5366,10 @@ static int perf_tp_filter_match(struct p
+ {
+ 	void *record = data->raw->data;
+ 
++	/* only top level events have filters set */
++	if (event->parent)
++		event = event->parent;
++
+ 	if (likely(!event->filter) || filter_match_preds(event->filter, record))
+ 		return 1;
+ 	return 0;
diff --git a/patches/recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch b/patches/recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch
new file mode 100644
index 0000000..36e653e
--- /dev/null
+++ b/patches/recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch
@@ -0,0 +1,31 @@
+From c84da8b9ad3761eef43811181c7e896e9834b26b Mon Sep 17 00:00:00 2001
+From: libin <huawei.libin@huawei.com>
+Date: Tue, 3 Nov 2015 08:58:47 +0800
+Subject: recordmcount: Fix endianness handling bug for nop_mcount
+
+commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.
+
+In nop_mcount, shdr->sh_offset and welp->r_offset should handle
+endianness properly, otherwise it will trigger Segmentation fault
+if the recordmcount main and file.o have different endianness.
+
+Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com
+
+Signed-off-by: Li Bin <huawei.libin@huawei.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ scripts/recordmcount.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/scripts/recordmcount.h
++++ b/scripts/recordmcount.h
+@@ -375,7 +375,7 @@ static void nop_mcount(Elf_Shdr const *c
+ 
+ 		if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
+ 			if (make_nop)
+-				ret = make_nop((void *)ehdr, shdr->sh_offset + relp->r_offset);
++				ret = make_nop((void *)ehdr, _w(shdr->sh_offset) + _w(relp->r_offset));
+ 			if (warn_on_notrace_sect && !once) {
+ 				printf("Section %s has mcount callers being ignored\n",
+ 				       txtname);
diff --git a/patches/revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch b/patches/revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch
new file mode 100644
index 0000000..e951a90
--- /dev/null
+++ b/patches/revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch
@@ -0,0 +1,170 @@
+From 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 Mon Sep 17 00:00:00 2001
+From: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
+Date: Thu, 29 Oct 2015 10:24:23 -0200
+Subject: Revert "dm mpath: fix stalls when handling invalid ioctls"
+
+commit 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 upstream.
+
+This reverts commit a1989b330093578ea5470bea0a00f940c444c466.
+
+That commit introduced a regression at least for the case of the SG_IO ioctl()
+running without CAP_SYS_RAWIO capability (e.g., unprivileged users) when there
+are no active paths: the ioctl() fails with the ENOTTY errno immediately rather
+than blocking due to queue_if_no_path until a path becomes active, for example.
+
+That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices
+(qemu "-device scsi-block" [1], libvirt "<disk type='block' device='lun'>" [2])
+from multipath devices; which leads to SCSI/filesystem errors in such a guest.
+
+More general scenarios can hit that regression too. The following demonstration
+employs a SG_IO ioctl() with a standard SCSI INQUIRY command for this objective
+(some output & user changes omitted for brevity and comments added for clarity).
+
+Reverting that commit restores normal operation (queueing) in failing scenarios;
+tested on linux-next (next-20151022).
+
+1) Test-case is based on sg_simple0 [3] (just SG_IO; remove SG_GET_VERSION_NUM)
+
+    $ cat sg_simple0.c
+    ... see [3] ...
+    $ sed '/SG_GET_VERSION_NUM/,/}/d' sg_simple0.c > sgio_inquiry.c
+    $ gcc sgio_inquiry.c -o sgio_inquiry
+
+2) The ioctl() works fine with active paths present.
+
+    # multipath -l 85ag56
+    85ag56 (...) dm-19 IBM     ,2145
+    size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
+    |-+- policy='service-time 0' prio=0 status=active
+    | |- 8:0:11:0  sdz  65:144  active undef running
+    | `- 9:0:9:0   sdbf 67:144  active undef running
+    `-+- policy='service-time 0' prio=0 status=enabled
+      |- 8:0:12:0  sdae 65:224  active undef running
+      `- 9:0:12:0  sdbo 68:32   active undef running
+
+    $ ./sgio_inquiry /dev/mapper/85ag56
+    Some of the INQUIRY command's response:
+        IBM       2145              0000
+    INQUIRY duration=0 millisecs, resid=0
+
+3) The ioctl() fails with ENOTTY errno with _no_ active paths present,
+   for unprivileged users (rather than blocking due to queue_if_no_path).
+
+    # for path in $(multipath -l 85ag56 | grep -o 'sd[a-z]\+'); \
+          do multipathd -k"fail path $path"; done
+
+    # multipath -l 85ag56
+    85ag56 (...) dm-19 IBM     ,2145
+    size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw
+    |-+- policy='service-time 0' prio=0 status=enabled
+    | |- 8:0:11:0  sdz  65:144  failed undef running
+    | `- 9:0:9:0   sdbf 67:144  failed undef running
+    `-+- policy='service-time 0' prio=0 status=enabled
+      |- 8:0:12:0  sdae 65:224  failed undef running
+      `- 9:0:12:0  sdbo 68:32   failed undef running
+
+    $ ./sgio_inquiry /dev/mapper/85ag56
+    sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device
+
+4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285);
+   it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl().
+
+    $ dmesg
+    <...>
+    [] device-mapper: multipath: Failing path 65:144.
+    [] device-mapper: multipath: Failing path 67:144.
+    [] device-mapper: multipath: Failing path 65:224.
+    [] device-mapper: multipath: Failing path 68:32.
+    [] sgio_inquiry: sending ioctl 2285 to a partition!
+
+5) The ioctl() only works if the SYS_CAP_RAWIO capability is present
+   (then queueing happens -- in this example, queue_if_no_path is set);
+   this is due to a conditional check in scsi_verify_blk_ioctl().
+
+    # capsh --drop=cap_sys_rawio -- -c './sgio_inquiry /dev/mapper/85ag56'
+    sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device
+
+    # ./sgio_inquiry /dev/mapper/85ag56 &
+    [1] 72830
+
+    # cat /proc/72830/stack
+    [<c00000171c0df700>] 0xc00000171c0df700
+    [<c000000000015934>] __switch_to+0x204/0x350
+    [<c000000000152d4c>] msleep+0x5c/0x80
+    [<c00000000077dfb0>] dm_blk_ioctl+0x70/0x170
+    [<c000000000487c40>] blkdev_ioctl+0x2b0/0x9b0
+    [<c0000000003128e4>] block_ioctl+0x64/0xd0
+    [<c0000000002dd3b0>] do_vfs_ioctl+0x490/0x780
+    [<c0000000002dd774>] SyS_ioctl+0xd4/0xf0
+    [<c000000000009358>] system_call+0x38/0xd0
+
+6) This is the function call chain exercised in this analysis:
+
+SYSCALL_DEFINE3(ioctl, <...>) @ fs/ioctl.c
+    -> do_vfs_ioctl()
+        -> vfs_ioctl()
+            ...
+            error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
+            ...
+                -> dm_blk_ioctl() @ drivers/md/dm.c
+                    -> multipath_ioctl() @ drivers/md/dm-mpath.c
+                        ...
+                        (bdev = NULL, due to no active paths)
+                        ...
+                        if (!bdev || <...>) {
+                            int err = scsi_verify_blk_ioctl(NULL, cmd);
+                            if (err)
+                                r = err;
+                        }
+                        ...
+                            -> scsi_verify_blk_ioctl() @ block/scsi_ioctl.c
+                                ...
+                                if (bd && bd == bd->bd_contains) // not taken (bd = NULL)
+                                    return 0;
+                                ...
+                                if (capable(CAP_SYS_RAWIO)) // not taken (unprivileged user)
+                                    return 0;
+                                ...
+                                printk_ratelimited(KERN_WARNING
+                                           "%s: sending ioctl %x to a partition!\n" <...>);
+
+                                return -ENOIOCTLCMD;
+                            <-
+                        ...
+                        return r ? : <...>
+                    <-
+            ...
+            if (error == -ENOIOCTLCMD)
+                error = -ENOTTY;
+             out:
+                return error;
+            ...
+
+Links:
+[1] http://git.qemu.org/?p=qemu.git;a=commit;h=336a6915bc7089fb20fea4ba99972ad9a97c5f52
+[2] https://libvirt.org/formatdomain.html#elementsDisks (see 'disk' -> 'device')
+[3] http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html (Revision 1.2, 2002-05-03)
+
+Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/md/dm-mpath.c |    7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/md/dm-mpath.c
++++ b/drivers/md/dm-mpath.c
+@@ -1553,11 +1553,8 @@ static int multipath_ioctl(struct dm_tar
+ 	/*
+ 	 * Only pass ioctls through if the device sizes match exactly.
+ 	 */
+-	if (!bdev || ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT) {
+-		int err = scsi_verify_blk_ioctl(NULL, cmd);
+-		if (err)
+-			r = err;
+-	}
++	if (!r && ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT)
++		r = scsi_verify_blk_ioctl(NULL, cmd);
+ 
+ 	return r ? : __blkdev_driver_ioctl(bdev, mode, cmd, arg);
+ }
diff --git a/patches/scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch b/patches/scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch
new file mode 100644
index 0000000..78d2398
--- /dev/null
+++ b/patches/scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch
@@ -0,0 +1,83 @@
+From 40998193560dab6c3ce8d25f4fa58a23e252ef38 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Mon, 19 Oct 2015 16:35:46 +0200
+Subject: scsi: restart list search after unlock in scsi_remove_target
+
+commit 40998193560dab6c3ce8d25f4fa58a23e252ef38 upstream.
+
+When dropping a lock while iterating a list we must restart the search
+as other threads could have manipulated the list under us.  Without this
+we can get stuck in an endless loop.  This bug was introduced by
+
+commit bc3f02a795d3b4faa99d37390174be2a75d091bd
+Author: Dan Williams <djbw@fb.com>
+Date:   Tue Aug 28 22:12:10 2012 -0700
+
+    [SCSI] scsi_remove_target: fix softlockup regression on hot remove
+
+Which was itself trying to fix a reported soft lockup issue
+
+http://thread.gmane.org/gmane.linux.kernel/1348679
+
+However, we believe even with this revert of the original patch, the soft
+lockup problem has been fixed by
+
+commit f2495e228fce9f9cec84367547813cbb0d6db15a
+Author: James Bottomley <JBottomley@Parallels.com>
+Date:   Tue Jan 21 07:01:41 2014 -0800
+
+    [SCSI] dual scan thread bug fix
+
+Thanks go to Dan Williams <dan.j.williams@intel.com> for tracking all this
+prior history down.
+
+Reported-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Tested-by: Johannes Thumshirn <jthumshirn@suse.de>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd
+Signed-off-by: James Bottomley <JBottomley@Odin.com>
+[lizf: Backported to 3.4: adjust context]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/scsi/scsi_sysfs.c |   16 ++++------------
+ 1 file changed, 4 insertions(+), 12 deletions(-)
+
+--- a/drivers/scsi/scsi_sysfs.c
++++ b/drivers/scsi/scsi_sysfs.c
+@@ -1020,31 +1020,23 @@ static void __scsi_remove_target(struct
+ void scsi_remove_target(struct device *dev)
+ {
+ 	struct Scsi_Host *shost = dev_to_shost(dev->parent);
+-	struct scsi_target *starget, *last = NULL;
++	struct scsi_target *starget;
+ 	unsigned long flags;
+ 
+-	/* remove targets being careful to lookup next entry before
+-	 * deleting the last
+-	 */
++restart:
+ 	spin_lock_irqsave(shost->host_lock, flags);
+ 	list_for_each_entry(starget, &shost->__targets, siblings) {
+ 		if (starget->state == STARGET_DEL)
+ 			continue;
+ 		if (starget->dev.parent == dev || &starget->dev == dev) {
+-			/* assuming new targets arrive at the end */
+ 			starget->reap_ref++;
+ 			spin_unlock_irqrestore(shost->host_lock, flags);
+-			if (last)
+-				scsi_target_reap(last);
+-			last = starget;
+ 			__scsi_remove_target(starget);
+-			spin_lock_irqsave(shost->host_lock, flags);
++			scsi_target_reap(starget);
++			goto restart;
+ 		}
+ 	}
+ 	spin_unlock_irqrestore(shost->host_lock, flags);
+-
+-	if (last)
+-		scsi_target_reap(last);
+ }
+ EXPORT_SYMBOL(scsi_remove_target);
+ 
diff --git a/patches/scsi_sysfs-fix-queue_ramp_up_period-return-code.patch b/patches/scsi_sysfs-fix-queue_ramp_up_period-return-code.patch
new file mode 100644
index 0000000..4b302bb
--- /dev/null
+++ b/patches/scsi_sysfs-fix-queue_ramp_up_period-return-code.patch
@@ -0,0 +1,33 @@
+From 863e02d0e173bb9d8cea6861be22820b25c076cc Mon Sep 17 00:00:00 2001
+From: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+Date: Tue, 27 Oct 2015 10:49:54 +0100
+Subject: scsi_sysfs: Fix queue_ramp_up_period return code
+
+commit 863e02d0e173bb9d8cea6861be22820b25c076cc upstream.
+
+Writing a number to /sys/bus/scsi/devices/<sdev>/queue_ramp_up_period
+returns the value of that number instead of the number of bytes written.
+This behavior can confuse programs expecting POSIX write() semantics.
+Fix this by returning the number of bytes written instead.
+
+Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/scsi/scsi_sysfs.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/scsi_sysfs.c
++++ b/drivers/scsi/scsi_sysfs.c
+@@ -793,7 +793,7 @@ sdev_store_queue_ramp_up_period(struct d
+ 		return -EINVAL;
+ 
+ 	sdev->queue_ramp_up_period = msecs_to_jiffies(period);
+-	return period;
++	return count;
+ }
+ 
+ static struct device_attribute sdev_attr_queue_ramp_up_period =
diff --git a/patches/series b/patches/series
index e69de29..b25976b 100644
--- a/patches/series
+++ b/patches/series
@@ -0,0 +1,32 @@
+mac80211-fix-driver-rssi-event-calculations.patch
+wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch
+mwifiex-fix-mwifiex_rdeeprom_read.patch
+devres-fix-a-for-loop-bounds-check.patch
+arm-pxa-remove-incorrect-__init-annotation-on-pxa27x_set_pwrmode.patch
+mips-atomic-fix-comment-describing-atomic64_add_unless-s-return-value.patch
+recordmcount-fix-endianness-handling-bug-for-nop_mcount.patch
+ipv6-fix-tunnel-error-handling.patch
+scsi-restart-list-search-after-unlock-in-scsi_remove_target.patch
+net-fix-a-race-in-dst_release.patch
+fs-cache-increase-reference-of-parent-after-registering-netfs-success.patch
+fs-cache-don-t-override-netfs-s-primary_index-if-registering-failed.patch
+fs-cache-handle-a-write-to-the-page-immediately-beyond-the-eof-marker.patch
+hid-core-avoid-uninitialized-buffer-access.patch
+mtd-mtdpart-fix-add_mtd_partitions-error-path.patch
+iommu-vt-d-fix-atsr-handling-for-root-complex-integrated-endpoints.patch
+ext4-jbd2-ensure-entering-into-panic-after-recording-an-error-in-superblock.patch
+bluetooth-ath3k-add-support-of-ar3012-0cf3-817b-device.patch
+staging-rtl8712-add-device-id-for-sitecom-wla2100.patch
+acpi-use-correct-irq-when-uninstalling-acpi-interrupt-handler.patch
+alsa-hda-disable-64bit-address-for-creative-hda-controllers.patch
+megaraid_sas-do-not-use-page_size-for-max_sectors.patch
+revert-dm-mpath-fix-stalls-when-handling-invalid-ioctls.patch
+crypto-algif_hash-only-export-and-import-on-sockets-with-data.patch
+megaraid_sas-smap-restriction-do-not-access-user-memory-from-ioctl-code.patch
+alsa-hda-apply-pin-fixup-for-hp-probook-6550b.patch
+firewire-ohci-fix-jmicron-jmb38x-it-context-discovery.patch
+x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch
+btrfs-fix-race-leading-to-bug_on-when-running-delalloc-for-nodatacow.patch
+perf-fix-inherited-events-vs.-tracepoint-filters.patch
+scsi_sysfs-fix-queue_ramp_up_period-return-code.patch
+binfmt_elf-don-t-clobber-passed-executable-s-file-header.patch
diff --git a/patches/staging-rtl8712-add-device-id-for-sitecom-wla2100.patch b/patches/staging-rtl8712-add-device-id-for-sitecom-wla2100.patch
new file mode 100644
index 0000000..bdabc58
--- /dev/null
+++ b/patches/staging-rtl8712-add-device-id-for-sitecom-wla2100.patch
@@ -0,0 +1,29 @@
+From 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 Mon Sep 17 00:00:00 2001
+From: Larry Finger <Larry.Finger@lwfinger.net>
+Date: Sun, 18 Oct 2015 22:14:48 -0500
+Subject: staging: rtl8712: Add device ID for Sitecom WLA2100
+
+commit 1e6e63283691a2a9048a35d9c6c59cf0abd342e4 upstream.
+
+This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file
+was checked to verify that the addition is correct.
+
+Reported-by: Frans van de Wiel <fvdw@fvdw.eu>
+Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
+Cc: Frans van de Wiel <fvdw@fvdw.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/staging/rtl8712/usb_intf.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/staging/rtl8712/usb_intf.c
++++ b/drivers/staging/rtl8712/usb_intf.c
+@@ -147,6 +147,7 @@ static struct usb_device_id rtl871x_usb_
+ 	{USB_DEVICE(0x0DF6, 0x0058)},
+ 	{USB_DEVICE(0x0DF6, 0x0049)},
+ 	{USB_DEVICE(0x0DF6, 0x004C)},
++	{USB_DEVICE(0x0DF6, 0x006C)},
+ 	{USB_DEVICE(0x0DF6, 0x0064)},
+ 	/* Skyworth */
+ 	{USB_DEVICE(0x14b2, 0x3300)},
diff --git a/patches/wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch b/patches/wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch
new file mode 100644
index 0000000..09d8c2d
--- /dev/null
+++ b/patches/wm831x_power-use-irqf_oneshot-to-request-threaded-irqs.patch
@@ -0,0 +1,50 @@
+From 90adf98d9530054b8e665ba5a928de4307231d84 Mon Sep 17 00:00:00 2001
+From: Valentin Rothberg <valentinrothberg@gmail.com>
+Date: Tue, 22 Sep 2015 19:00:40 +0200
+Subject: wm831x_power: Use IRQF_ONESHOT to request threaded IRQs
+
+commit 90adf98d9530054b8e665ba5a928de4307231d84 upstream.
+
+Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
+threaded IRQs without a primary handler need to be requested with
+IRQF_ONESHOT, otherwise the request will fail.
+
+scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue.
+
+Fixes: b5874f33bbaf ("wm831x_power: Use genirq")
+Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
+Signed-off-by: Sebastian Reichel <sre@kernel.org>
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ drivers/power/wm831x_power.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/power/wm831x_power.c
++++ b/drivers/power/wm831x_power.c
+@@ -567,7 +567,7 @@ static __devinit int wm831x_power_probe(
+ 
+ 	irq = platform_get_irq_byname(pdev, "SYSLO");
+ 	ret = request_threaded_irq(irq, NULL, wm831x_syslo_irq,
+-				   IRQF_TRIGGER_RISING, "System power low",
++				   IRQF_TRIGGER_RISING | IRQF_ONESHOT, "System power low",
+ 				   power);
+ 	if (ret != 0) {
+ 		dev_err(&pdev->dev, "Failed to request SYSLO IRQ %d: %d\n",
+@@ -577,7 +577,7 @@ static __devinit int wm831x_power_probe(
+ 
+ 	irq = platform_get_irq_byname(pdev, "PWR SRC");
+ 	ret = request_threaded_irq(irq, NULL, wm831x_pwr_src_irq,
+-				   IRQF_TRIGGER_RISING, "Power source",
++				   IRQF_TRIGGER_RISING | IRQF_ONESHOT, "Power source",
+ 				   power);
+ 	if (ret != 0) {
+ 		dev_err(&pdev->dev, "Failed to request PWR SRC IRQ %d: %d\n",
+@@ -588,7 +588,7 @@ static __devinit int wm831x_power_probe(
+ 	for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
+ 		irq = platform_get_irq_byname(pdev, wm831x_bat_irqs[i]);
+ 		ret = request_threaded_irq(irq, NULL, wm831x_bat_irq,
+-					   IRQF_TRIGGER_RISING,
++					   IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ 					   wm831x_bat_irqs[i],
+ 					   power);
+ 		if (ret != 0) {
diff --git a/patches/x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch b/patches/x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch
new file mode 100644
index 0000000..dce8226
--- /dev/null
+++ b/patches/x86-cpu-call-verify_cpu-after-having-entered-long-mode-too.patch
@@ -0,0 +1,116 @@
+From 04633df0c43d710e5f696b06539c100898678235 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Thu, 5 Nov 2015 16:57:56 +0100
+Subject: x86/cpu: Call verify_cpu() after having entered long mode too
+
+commit 04633df0c43d710e5f696b06539c100898678235 upstream.
+
+When we get loaded by a 64-bit bootloader, kernel entry point is
+startup_64 in head_64.S. We don't trust any and all bootloaders because
+some will fiddle with CPU configuration so we go ahead and massage each
+CPU into sanity again.
+
+For example, some dell BIOSes have this XD disable feature which set
+IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
+for other OSes but Linux sure doesn't need it.
+
+A similar thing is present in the Surface 3 firmware - see
+https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
+only on the BSP:
+
+  # rdmsr -a 0x1a0
+  400850089
+  850089
+  850089
+  850089
+
+I know, right?!
+
+There's not even an off switch in there.
+
+So fix all those cases by sanitizing the 64-bit entry point too. For
+that, make verify_cpu() callable in 64-bit mode also.
+
+Requested-and-debugged-by: "H. Peter Anvin" <hpa@zytor.com>
+Reported-and-tested-by: Bastien Nocera <bugzilla@hadess.net>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: Matt Fleming <matt@codeblueprint.co.uk>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.de
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+[lizf: Backported to 3.4: adjust context]
+Signed-off-by: Zefan Li <lizefan@huawei.com>
+---
+ arch/x86/kernel/head_64.S    |    8 ++++++++
+ arch/x86/kernel/verify_cpu.S |   12 +++++++-----
+ 2 files changed, 15 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kernel/head_64.S
++++ b/arch/x86/kernel/head_64.S
+@@ -45,6 +45,9 @@ L3_START_KERNEL = pud_index(__START_KERN
+ 	.globl startup_64
+ startup_64:
+ 
++	/* Sanitize CPU configuration */
++	call verify_cpu
++
+ 	/*
+ 	 * At this point the CPU runs in 64bit mode CS.L = 1 CS.D = 1,
+ 	 * and someone has loaded an identity mapped page table
+@@ -160,6 +163,9 @@ ENTRY(secondary_startup_64)
+ 	 * after the boot processor executes this code.
+ 	 */
+ 
++	/* Sanitize CPU configuration */
++	call verify_cpu
++
+ 	/* Enable PAE mode and PGE */
+ 	movl	$(X86_CR4_PAE | X86_CR4_PGE), %eax
+ 	movq	%rax, %cr4
+@@ -253,6 +259,8 @@ ENTRY(secondary_startup_64)
+ 	pushq	%rax		# target address in negative space
+ 	lretq
+ 
++#include "verify_cpu.S"
++
+ 	/* SMP bootup changes these two */
+ 	__REFDATA
+ 	.align	8
+--- a/arch/x86/kernel/verify_cpu.S
++++ b/arch/x86/kernel/verify_cpu.S
+@@ -34,10 +34,11 @@
+ #include <asm/msr-index.h>
+ 
+ verify_cpu:
+-	pushfl				# Save caller passed flags
+-	pushl	$0			# Kill any dangerous flags
+-	popfl
++	pushf				# Save caller passed flags
++	push	$0			# Kill any dangerous flags
++	popf
+ 
++#ifndef __x86_64__
+ 	pushfl				# standard way to check for cpuid
+ 	popl	%eax
+ 	movl	%eax,%ebx
+@@ -48,6 +49,7 @@ verify_cpu:
+ 	popl	%eax
+ 	cmpl	%eax,%ebx
+ 	jz	verify_cpu_no_longmode	# cpu has no cpuid
++#endif
+ 
+ 	movl	$0x0,%eax		# See if cpuid 1 is implemented
+ 	cpuid
+@@ -130,10 +132,10 @@ verify_cpu_sse_test:
+ 	jmp	verify_cpu_sse_test	# try again
+ 
+ verify_cpu_no_longmode:
+-	popfl				# Restore caller passed flags
++	popf				# Restore caller passed flags
+ 	movl $1,%eax
+ 	ret
+ verify_cpu_sse_ok:
+-	popfl				# Restore caller passed flags
++	popf				# Restore caller passed flags
+ 	xorl %eax, %eax
+ 	ret