--- /dev/null
+From 7dc661bd8d3261053b69e4e2d0050cd1ee540fc1 Mon Sep 17 00:00:00 2001
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Date: Tue, 26 Feb 2019 13:38:16 +0900
+Subject: ALSA: bebob: use more identical mod_alias for Saffire Pro 10 I/O against Liquid Saffire 56
+
+From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+
+commit 7dc661bd8d3261053b69e4e2d0050cd1ee540fc1 upstream.
+
+ALSA bebob driver has an entry for Focusrite Saffire Pro 10 I/O. The
+entry matches vendor_id in root directory and model_id in unit
+directory of configuration ROM for IEEE 1394 bus.
+
+On the other hand, configuration ROM of Focusrite Liquid Saffire 56
+has the same vendor_id and model_id. This device is an application of
+TCAT Dice (TCD2220 a.k.a Dice Jr.) however ALSA bebob driver can be
+bound to it randomly instead of ALSA dice driver. At present, drivers
+in ALSA firewire stack can not handle this situation appropriately.
+
+This commit uses more identical mod_alias for Focusrite Saffire Pro 10
+I/O in ALSA bebob driver.
+
+$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
+ ROM header and bus information block
+ -----------------------------------------------------------------
+400 042a829d bus_info_length 4, crc_length 42, crc 33437
+404 31333934 bus_name "1394"
+408 f0649222 irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 100,
+ max_rec 9 (1024), max_rom 2, gen 2, spd 2 (S400)
+40c 00130e01 company_id 00130e |
+410 000606e0 device_id 01000606e0 | EUI-64 00130e01000606e0
+
+ root directory
+ -----------------------------------------------------------------
+414 0009d31c directory_length 9, crc 54044
+418 04000014 hardware version
+41c 0c0083c0 node capabilities per IEEE 1394
+420 0300130e vendor
+424 81000012 --> descriptor leaf at 46c
+428 17000006 model
+42c 81000016 --> descriptor leaf at 484
+430 130120c2 version
+434 d1000002 --> unit directory at 43c
+438 d4000006 --> dependent info directory at 450
+
+ unit directory at 43c
+ -----------------------------------------------------------------
+43c 0004707c directory_length 4, crc 28796
+440 1200a02d specifier id: 1394 TA
+444 13010001 version: AV/C
+448 17000006 model
+44c 81000013 --> descriptor leaf at 498
+
+ dependent info directory at 450
+ -----------------------------------------------------------------
+450 000637c7 directory_length 6, crc 14279
+454 120007f5 specifier id
+458 13000001 version
+45c 3affffc7 (immediate value)
+460 3b100000 (immediate value)
+464 3cffffc7 (immediate value)
+468 3d600000 (immediate value)
+
+ descriptor leaf at 46c
+ -----------------------------------------------------------------
+46c 00056f3b leaf_length 5, crc 28475
+470 00000000 textual descriptor
+474 00000000 minimal ASCII
+478 466f6375 "Focu"
+47c 73726974 "srit"
+480 65000000 "e"
+
+ descriptor leaf at 484
+ -----------------------------------------------------------------
+484 0004a165 leaf_length 4, crc 41317
+488 00000000 textual descriptor
+48c 00000000 minimal ASCII
+490 50726f31 "Pro1"
+494 30494f00 "0IO"
+
+ descriptor leaf at 498
+ -----------------------------------------------------------------
+498 0004a165 leaf_length 4, crc 41317
+49c 00000000 textual descriptor
+4a0 00000000 minimal ASCII
+4a4 50726f31 "Pro1"
+4a8 30494f00 "0IO"
+
+$ python2 crpp < /sys/bus/firewire/devices/fw1/config_rom
+ ROM header and bus information block
+ -----------------------------------------------------------------
+400 040442e4 bus_info_length 4, crc_length 4, crc 17124
+404 31333934 bus_name "1394"
+408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255,
+ max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400)
+40c 00130e04 company_id 00130e |
+410 018001e9 device_id 04018001e9 | EUI-64 00130e04018001e9
+
+ root directory
+ -----------------------------------------------------------------
+414 00065612 directory_length 6, crc 22034
+418 0300130e vendor
+41c 8100000a --> descriptor leaf at 444
+420 17000006 model
+424 8100000e --> descriptor leaf at 45c
+428 0c0087c0 node capabilities per IEEE 1394
+42c d1000001 --> unit directory at 430
+
+ unit directory at 430
+ -----------------------------------------------------------------
+430 000418a0 directory_length 4, crc 6304
+434 1200130e specifier id
+438 13000001 version
+43c 17000006 model
+440 8100000f --> descriptor leaf at 47c
+
+ descriptor leaf at 444
+ -----------------------------------------------------------------
+444 00056f3b leaf_length 5, crc 28475
+448 00000000 textual descriptor
+44c 00000000 minimal ASCII
+450 466f6375 "Focu"
+454 73726974 "srit"
+458 65000000 "e"
+
+ descriptor leaf at 45c
+ -----------------------------------------------------------------
+45c 000762c6 leaf_length 7, crc 25286
+460 00000000 textual descriptor
+464 00000000 minimal ASCII
+468 4c495155 "LIQU"
+46c 49445f53 "ID_S"
+470 41464649 "AFFI"
+474 52455f35 "RE_5"
+478 36000000 "6"
+
+ descriptor leaf at 47c
+ -----------------------------------------------------------------
+47c 000762c6 leaf_length 7, crc 25286
+480 00000000 textual descriptor
+484 00000000 minimal ASCII
+488 4c495155 "LIQU"
+48c 49445f53 "ID_S"
+490 41464649 "AFFI"
+494 52455f35 "RE_5"
+498 36000000 "6"
+
+Cc: <stable@vger.kernel.org> # v3.16+
+Fixes: 25784ec2d034 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series")
+Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/firewire/bebob/bebob.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/sound/firewire/bebob/bebob.c
++++ b/sound/firewire/bebob/bebob.c
+@@ -474,7 +474,19 @@ static const struct ieee1394_device_id b
+ /* Focusrite, SaffirePro 26 I/O */
+ SND_BEBOB_DEV_ENTRY(VEN_FOCUSRITE, 0x00000003, &saffirepro_26_spec),
+ /* Focusrite, SaffirePro 10 I/O */
+- SND_BEBOB_DEV_ENTRY(VEN_FOCUSRITE, 0x00000006, &saffirepro_10_spec),
++ {
++ // The combination of vendor_id and model_id is the same as the
++ // same as the one of Liquid Saffire 56.
++ .match_flags = IEEE1394_MATCH_VENDOR_ID |
++ IEEE1394_MATCH_MODEL_ID |
++ IEEE1394_MATCH_SPECIFIER_ID |
++ IEEE1394_MATCH_VERSION,
++ .vendor_id = VEN_FOCUSRITE,
++ .model_id = 0x000006,
++ .specifier_id = 0x00a02d,
++ .version = 0x010001,
++ .driver_data = (kernel_ulong_t)&saffirepro_10_spec,
++ },
+ /* Focusrite, Saffire(no label and LE) */
+ SND_BEBOB_DEV_ENTRY(VEN_FOCUSRITE, MODEL_FOCUSRITE_SAFFIRE_BOTH,
+ &saffire_spec),
--- /dev/null
+From b761dcf1217760a42f7897c31dcb649f59b2333e Mon Sep 17 00:00:00 2001
+From: Xiao Ni <xni@redhat.com>
+Date: Fri, 8 Mar 2019 23:52:05 +0800
+Subject: It's wrong to add len to sector_nr in raid10 reshape twice
+
+From: Xiao Ni <xni@redhat.com>
+
+commit b761dcf1217760a42f7897c31dcb649f59b2333e upstream.
+
+In reshape_request it already adds len to sector_nr already. It's wrong to add len to
+sector_nr again after adding pages to bio. If there is bad block it can't copy one chunk
+at a time, it needs to goto read_more. Now the sector_nr is wrong. It can cause data
+corruption.
+
+Cc: stable@vger.kernel.org # v3.16+
+Signed-off-by: Xiao Ni <xni@redhat.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid10.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -4489,7 +4489,6 @@ bio_full:
+ atomic_inc(&r10_bio->remaining);
+ read_bio->bi_next = NULL;
+ generic_make_request(read_bio);
+- sector_nr += nr_sectors;
+ sectors_done += nr_sectors;
+ if (sector_nr <= last)
+ goto read_more;
--- /dev/null
+From 5c27ff5db1491a947264d6d4e4cbe43ae6535bae Mon Sep 17 00:00:00 2001
+From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Date: Mon, 18 Feb 2019 20:45:40 +0300
+Subject: mmc: tmio_mmc_core: don't claim spurious interrupts
+
+From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+
+commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream.
+
+I have encountered an interrupt storm during the eMMC chip probing (and
+the chip finally didn't get detected). It turned out that U-Boot left
+the DMAC interrupts enabled while the Linux driver didn't use those.
+The SDHI driver's interrupt handler somehow assumes that, even if an
+SDIO interrupt didn't happen, it should return IRQ_HANDLED. I think
+that if none of the enabled interrupts happened and got handled, we
+should return IRQ_NONE -- that way the kernel IRQ code recoginizes
+a spurious interrupt and masks it off pretty quickly...
+
+Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
+Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
+Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/tmio_mmc_pio.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/host/tmio_mmc_pio.c
++++ b/drivers/mmc/host/tmio_mmc_pio.c
+@@ -675,7 +675,7 @@ static bool __tmio_mmc_sdcard_irq(struct
+ return false;
+ }
+
+-static void tmio_mmc_sdio_irq(int irq, void *devid)
++static bool tmio_mmc_sdio_irq(int irq, void *devid)
+ {
+ struct tmio_mmc_host *host = devid;
+ struct mmc_host *mmc = host->mmc;
+@@ -684,7 +684,7 @@ static void tmio_mmc_sdio_irq(int irq, v
+ unsigned int sdio_status;
+
+ if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
+- return;
++ return false;
+
+ status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
+ ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
+@@ -697,6 +697,8 @@ static void tmio_mmc_sdio_irq(int irq, v
+
+ if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
+ mmc_signal_sdio_irq(mmc);
++
++ return ireg;
+ }
+
+ irqreturn_t tmio_mmc_irq(int irq, void *devid)
+@@ -718,9 +720,10 @@ irqreturn_t tmio_mmc_irq(int irq, void *
+ if (__tmio_mmc_sdcard_irq(host, ireg, status))
+ return IRQ_HANDLED;
+
+- tmio_mmc_sdio_irq(irq, devid);
++ if (tmio_mmc_sdio_irq(irq, devid))
++ return IRQ_HANDLED;
+
+- return IRQ_HANDLED;
++ return IRQ_NONE;
+ }
+ EXPORT_SYMBOL(tmio_mmc_irq);
+
--- /dev/null
+From d20dc1493db438fbbfb7733adc82f472dd8a0789 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Wed, 24 May 2017 17:53:55 +0300
+Subject: of: Support const and non-const use for to_of_node()
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit d20dc1493db438fbbfb7733adc82f472dd8a0789 upstream.
+
+Turn to_of_node() into a macro in order to support both const and
+non-const use. Additionally make the fwnode argument to is_of_node() const
+as well.
+
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
+Signed-off-by: Rob Herring <robh@kernel.org>
+Cc: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/of.h | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+--- a/include/linux/of.h
++++ b/include/linux/of.h
+@@ -148,16 +148,20 @@ extern raw_spinlock_t devtree_lock;
+ #ifdef CONFIG_OF
+ void of_core_init(void);
+
+-static inline bool is_of_node(struct fwnode_handle *fwnode)
++static inline bool is_of_node(const struct fwnode_handle *fwnode)
+ {
+ return !IS_ERR_OR_NULL(fwnode) && fwnode->type == FWNODE_OF;
+ }
+
+-static inline struct device_node *to_of_node(struct fwnode_handle *fwnode)
+-{
+- return is_of_node(fwnode) ?
+- container_of(fwnode, struct device_node, fwnode) : NULL;
+-}
++#define to_of_node(__fwnode) \
++ ({ \
++ typeof(__fwnode) __to_of_node_fwnode = (__fwnode); \
++ \
++ is_of_node(__to_of_node_fwnode) ? \
++ container_of(__to_of_node_fwnode, \
++ struct device_node, fwnode) : \
++ NULL; \
++ })
+
+ static inline bool of_have_populated_dt(void)
+ {
+@@ -529,12 +533,12 @@ static inline void of_core_init(void)
+ {
+ }
+
+-static inline bool is_of_node(struct fwnode_handle *fwnode)
++static inline bool is_of_node(const struct fwnode_handle *fwnode)
+ {
+ return false;
+ }
+
+-static inline struct device_node *to_of_node(struct fwnode_handle *fwnode)
++static inline struct device_node *to_of_node(const struct fwnode_handle *fwnode)
+ {
+ return NULL;
+ }
--- /dev/null
+From f764c58b7faa26f5714e6907f892abc2bc0de4f8 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Fri, 15 Mar 2019 09:14:10 +0100
+Subject: perf/x86: Fixup typo in stub functions
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit f764c58b7faa26f5714e6907f892abc2bc0de4f8 upstream.
+
+Guenter reported a build warning for CONFIG_CPU_SUP_INTEL=n:
+
+ > With allmodconfig-CONFIG_CPU_SUP_INTEL, this patch results in:
+ >
+ > In file included from arch/x86/events/amd/core.c:8:0:
+ > arch/x86/events/amd/../perf_event.h:1036:45: warning: ‘struct cpu_hw_event’ declared inside parameter list will not be visible outside of this definition or declaration
+ > static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
+
+While harmless (an unsed pointer is an unused pointer, no matter the type)
+it needs fixing.
+
+Reported-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Fixes: d01b1f96a82e ("perf/x86/intel: Make cpuc allocations consistent")
+Link: http://lkml.kernel.org/r/20190315081410.GR5996@hirez.programming.kicks-ass.net
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/events/perf_event.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/events/perf_event.h
++++ b/arch/x86/events/perf_event.h
+@@ -996,12 +996,12 @@ static inline int intel_pmu_init(void)
+ return 0;
+ }
+
+-static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
++static inline int intel_cpuc_prepare(struct cpu_hw_events *cpuc, int cpu)
+ {
+ return 0;
+ }
+
+-static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
++static inline void intel_cpuc_finish(struct cpu_hw_events *cpuc)
+ {
+ }
+
rxrpc-fix-client-call-queueing-waiting-for-channel.patch
gro_cells-make-sure-device-is-up-in-gro_cells_receive.patch
tcp-dccp-remove-reqsk_put-from-inet_child_forget.patch
+perf-x86-fixup-typo-in-stub-functions.patch
+alsa-bebob-use-more-identical-mod_alias-for-saffire-pro-10-i-o-against-liquid-saffire-56.patch
+it-s-wrong-to-add-len-to-sector_nr-in-raid10-reshape-twice.patch
+mmc-tmio_mmc_core-don-t-claim-spurious-interrupts.patch
+of-support-const-and-non-const-use-for-to_of_node.patch
+vhost-vsock-fix-vhost-vsock-cid-hashing-inconsistent.patch
--- /dev/null
+From 7fbe078c37aba3088359c9256c1a1d0c3e39ee81 Mon Sep 17 00:00:00 2001
+From: Zha Bin <zhabin@linux.alibaba.com>
+Date: Tue, 8 Jan 2019 16:07:03 +0800
+Subject: vhost/vsock: fix vhost vsock cid hashing inconsistent
+
+From: Zha Bin <zhabin@linux.alibaba.com>
+
+commit 7fbe078c37aba3088359c9256c1a1d0c3e39ee81 upstream.
+
+The vsock core only supports 32bit CID, but the Virtio-vsock spec define
+CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
+zero. This inconsistency causes one bug in vhost vsock driver. The
+scenarios is:
+
+ 0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock
+ object. And hash_min() is used to compute the hash key. hash_min() is
+ defined as:
+ (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)).
+ That means the hash algorithm has dependency on the size of macro
+ argument 'val'.
+ 0. In function vhost_vsock_set_cid(), a 64bit CID is passed to
+ hash_min() to compute the hash key when inserting a vsock object into
+ the hash table.
+ 0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min()
+ to compute the hash key when looking up a vsock for an CID.
+
+Because the different size of the CID, hash_min() returns different hash
+key, thus fails to look up the vsock object for an CID.
+
+To fix this bug, we keep CID as u64 in the IOCTLs and virtio message
+headers, but explicitly convert u64 to u32 when deal with the hash table
+and vsock core.
+
+Fixes: 834e772c8db0 ("vhost/vsock: fix use-after-free in network stack callers")
+Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.tex
+Signed-off-by: Zha Bin <zhabin@linux.alibaba.com>
+Reviewed-by: Liu Jiang <gerry@linux.alibaba.com>
+Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Shengjing Zhu <i@zhsj.me>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ drivers/vhost/vsock.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/vhost/vsock.c
++++ b/drivers/vhost/vsock.c
+@@ -640,7 +640,7 @@ static int vhost_vsock_set_cid(struct vh
+ hash_del_rcu(&vsock->hash);
+
+ vsock->guest_cid = guest_cid;
+- hash_add_rcu(vhost_vsock_hash, &vsock->hash, guest_cid);
++ hash_add_rcu(vhost_vsock_hash, &vsock->hash, vsock->guest_cid);
+ spin_unlock_bh(&vhost_vsock_lock);
+
+ return 0;