--- /dev/null
+From 3c2cc72b63f776e81725f3da36e3e4c28c7058c8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 Feb 2020 10:44:27 -0800
+Subject: altera-stapl: altera_get_note: prevent write beyond end of 'key'
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Daniel Axtens <dja@axtens.net>
+
+[ Upstream commit 3745488e9d599916a0b40d45d3f30e3d4720288e ]
+
+altera_get_note is called from altera_init, where key is kzalloc(33).
+
+When the allocation functions are annotated to allow the compiler to see
+the sizes of objects, and with FORTIFY_SOURCE, we see:
+
+In file included from drivers/misc/altera-stapl/altera.c:14:0:
+In function ‘strlcpy’,
+ inlined from ‘altera_init’ at drivers/misc/altera-stapl/altera.c:2189:5:
+include/linux/string.h:378:4: error: call to ‘__write_overflow’ declared with attribute error: detected write beyond size of object passed as 1st parameter
+ __write_overflow();
+ ^~~~~~~~~~~~~~~~~~
+
+That refers to this code in altera_get_note:
+
+ if (key != NULL)
+ strlcpy(key, &p[note_strings +
+ get_unaligned_be32(
+ &p[note_table + (8 * i)])],
+ length);
+
+The error triggers because the length of 'key' is 33, but the copy
+uses length supplied as the 'length' parameter, which is always
+256. Split the size parameter into key_len and val_len, and use the
+appropriate length depending on what is being copied.
+
+Detected by compiler error, only compile-tested.
+
+Cc: "Igor M. Liplianin" <liplianin@netup.ru>
+Signed-off-by: Daniel Axtens <dja@axtens.net>
+Link: https://lore.kernel.org/r/20200120074344.504-2-dja@axtens.net
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Link: https://lore.kernel.org/r/202002251042.D898E67AC@keescook
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/misc/altera-stapl/altera.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c
+index d2ed3b9728b7c..94bde09d9323d 100644
+--- a/drivers/misc/altera-stapl/altera.c
++++ b/drivers/misc/altera-stapl/altera.c
+@@ -2126,8 +2126,8 @@ static int altera_execute(struct altera_state *astate,
+ return status;
+ }
+
+-static int altera_get_note(u8 *p, s32 program_size,
+- s32 *offset, char *key, char *value, int length)
++static int altera_get_note(u8 *p, s32 program_size, s32 *offset,
++ char *key, char *value, int keylen, int vallen)
+ /*
+ * Gets key and value of NOTE fields in the JBC file.
+ * Can be called in two modes: if offset pointer is NULL,
+@@ -2184,7 +2184,7 @@ static int altera_get_note(u8 *p, s32 program_size,
+ &p[note_table + (8 * i) + 4])];
+
+ if (value != NULL)
+- strlcpy(value, value_ptr, length);
++ strlcpy(value, value_ptr, vallen);
+
+ }
+ }
+@@ -2203,13 +2203,13 @@ static int altera_get_note(u8 *p, s32 program_size,
+ strlcpy(key, &p[note_strings +
+ get_unaligned_be32(
+ &p[note_table + (8 * i)])],
+- length);
++ keylen);
+
+ if (value != NULL)
+ strlcpy(value, &p[note_strings +
+ get_unaligned_be32(
+ &p[note_table + (8 * i) + 4])],
+- length);
++ vallen);
+
+ *offset = i + 1;
+ }
+@@ -2463,7 +2463,7 @@ int altera_init(struct altera_config *config, const struct firmware *fw)
+ __func__, (format_version == 2) ? "Jam STAPL" :
+ "pre-standardized Jam 1.1");
+ while (altera_get_note((u8 *)fw->data, fw->size,
+- &offset, key, value, 256) == 0)
++ &offset, key, value, 32, 256) == 0)
+ printk(KERN_INFO "%s: NOTE \"%s\" = \"%s\"\n",
+ __func__, key, value);
+ }
+--
+2.20.1
+
--- /dev/null
+From 8dc998eb511d33115e4f970fd51fe529d3837cfa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 28 Jan 2020 12:11:47 +0530
+Subject: ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes
+
+From: Kishon Vijay Abraham I <kishon@ti.com>
+
+[ Upstream commit 27f13774654ea6bd0b6fc9b97cce8d19e5735661 ]
+
+'dma-ranges' in a PCI bridge node does correctly set dma masks for PCI
+devices not described in the DT. Certain DRA7 platforms (e.g., DRA76)
+has RAM above 32-bit boundary (accessible with LPAE config) though the
+PCIe bridge will be able to access only 32-bits. Add 'dma-ranges'
+property in PCIe RC DT nodes to indicate the host bridge can access
+only 32 bits.
+
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/dra7.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
+index 7ce24b282d421..c1ef3201950ae 100644
+--- a/arch/arm/boot/dts/dra7.dtsi
++++ b/arch/arm/boot/dts/dra7.dtsi
+@@ -324,6 +324,7 @@
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x03000 0 0x00010000
+ 0x82000000 0 0x20013000 0x13000 0 0xffed000>;
++ dma-ranges = <0x02000000 0x0 0x00000000 0x00000000 0x1 0x00000000>;
+ bus-range = <0x00 0xff>;
+ #interrupt-cells = <1>;
+ num-lanes = <1>;
+@@ -376,6 +377,7 @@
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x03000 0 0x00010000
+ 0x82000000 0 0x30013000 0x13000 0 0xffed000>;
++ dma-ranges = <0x02000000 0x0 0x00000000 0x00000000 0x1 0x00000000>;
+ bus-range = <0x00 0xff>;
+ #interrupt-cells = <1>;
+ num-lanes = <1>;
+--
+2.20.1
+
--- /dev/null
+From 7f663f7e44c82c59ee872d9628d4e0fa2a4fc58f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 13:27:31 +0100
+Subject: block, bfq: fix overwrite of bfq_group pointer in
+ bfq_find_set_group()
+
+From: Carlo Nonato <carlo.nonato95@gmail.com>
+
+[ Upstream commit 14afc59361976c0ba39e3a9589c3eaa43ebc7e1d ]
+
+The bfq_find_set_group() function takes as input a blkcg (which represents
+a cgroup) and retrieves the corresponding bfq_group, then it updates the
+bfq internal group hierarchy (see comments inside the function for why
+this is needed) and finally it returns the bfq_group.
+In the hierarchy update cycle, the pointer holding the correct bfq_group
+that has to be returned is mistakenly used to traverse the hierarchy
+bottom to top, meaning that in each iteration it gets overwritten with the
+parent of the current group. Since the update cycle stops at root's
+children (depth = 2), the overwrite becomes a problem only if the blkcg
+describes a cgroup at a hierarchy level deeper than that (depth > 2). In
+this case the root's child that happens to be also an ancestor of the
+correct bfq_group is returned. The main consequence is that processes
+contained in a cgroup at depth greater than 2 are wrongly placed in the
+group described above by BFQ.
+
+This commits fixes this problem by using a different bfq_group pointer in
+the update cycle in order to avoid the overwrite of the variable holding
+the original group reference.
+
+Reported-by: Kwon Je Oh <kwonje.oh2@gmail.com>
+Signed-off-by: Carlo Nonato <carlo.nonato95@gmail.com>
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bfq-cgroup.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
+index 9fe5952d117d5..ecd3d0ec2f3b6 100644
+--- a/block/bfq-cgroup.c
++++ b/block/bfq-cgroup.c
+@@ -525,12 +525,13 @@ struct bfq_group *bfq_find_set_group(struct bfq_data *bfqd,
+ */
+ entity = &bfqg->entity;
+ for_each_entity(entity) {
+- bfqg = container_of(entity, struct bfq_group, entity);
+- if (bfqg != bfqd->root_group) {
+- parent = bfqg_parent(bfqg);
++ struct bfq_group *curr_bfqg = container_of(entity,
++ struct bfq_group, entity);
++ if (curr_bfqg != bfqd->root_group) {
++ parent = bfqg_parent(curr_bfqg);
+ if (!parent)
+ parent = bfqd->root_group;
+- bfq_group_set_parent(bfqg, parent);
++ bfq_group_set_parent(curr_bfqg, parent);
+ }
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 423e7e9ce85665ea9d390ea146dbc70565ba1b7e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Feb 2020 18:00:53 -0500
+Subject: dm bio record: save/restore bi_end_io and bi_integrity
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+[ Upstream commit 1b17159e52bb31f982f82a6278acd7fab1d3f67b ]
+
+Also, save/restore __bi_remaining in case the bio was used in a
+BIO_CHAIN (e.g. due to blk_queue_split).
+
+Suggested-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/dm-bio-record.h | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/drivers/md/dm-bio-record.h b/drivers/md/dm-bio-record.h
+index c82578af56a5b..2ea0360108e1d 100644
+--- a/drivers/md/dm-bio-record.h
++++ b/drivers/md/dm-bio-record.h
+@@ -20,8 +20,13 @@
+ struct dm_bio_details {
+ struct gendisk *bi_disk;
+ u8 bi_partno;
++ int __bi_remaining;
+ unsigned long bi_flags;
+ struct bvec_iter bi_iter;
++ bio_end_io_t *bi_end_io;
++#if defined(CONFIG_BLK_DEV_INTEGRITY)
++ struct bio_integrity_payload *bi_integrity;
++#endif
+ };
+
+ static inline void dm_bio_record(struct dm_bio_details *bd, struct bio *bio)
+@@ -30,6 +35,11 @@ static inline void dm_bio_record(struct dm_bio_details *bd, struct bio *bio)
+ bd->bi_partno = bio->bi_partno;
+ bd->bi_flags = bio->bi_flags;
+ bd->bi_iter = bio->bi_iter;
++ bd->__bi_remaining = atomic_read(&bio->__bi_remaining);
++ bd->bi_end_io = bio->bi_end_io;
++#if defined(CONFIG_BLK_DEV_INTEGRITY)
++ bd->bi_integrity = bio_integrity(bio);
++#endif
+ }
+
+ static inline void dm_bio_restore(struct dm_bio_details *bd, struct bio *bio)
+@@ -38,6 +48,11 @@ static inline void dm_bio_restore(struct dm_bio_details *bd, struct bio *bio)
+ bio->bi_partno = bd->bi_partno;
+ bio->bi_flags = bd->bi_flags;
+ bio->bi_iter = bd->bi_iter;
++ atomic_set(&bio->__bi_remaining, bd->__bi_remaining);
++ bio->bi_end_io = bd->bi_end_io;
++#if defined(CONFIG_BLK_DEV_INTEGRITY)
++ bio->bi_integrity = bd->bi_integrity;
++#endif
+ }
+
+ #endif
+--
+2.20.1
+
--- /dev/null
+From 64e7e851adbeb314ad7a74af8923806fa996a726 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Feb 2020 18:11:53 -0500
+Subject: dm integrity: use dm_bio_record and dm_bio_restore
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+[ Upstream commit 248aa2645aa7fc9175d1107c2593cc90d4af5a4e ]
+
+In cases where dec_in_flight() has to requeue the integrity_bio_wait
+work to transfer the rest of the data, the bio's __bi_remaining might
+already have been decremented to 0, e.g.: if bio passed to underlying
+data device was split via blk_queue_split().
+
+Use dm_bio_{record,restore} rather than effectively open-coding them in
+dm-integrity -- these methods now manage __bi_remaining too.
+
+Depends-on: f7f0b057a9c1 ("dm bio record: save/restore bi_end_io and bi_integrity")
+Reported-by: Daniel Glöckner <dg@emlix.com>
+Suggested-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/dm-integrity.c | 32 +++++++++-----------------------
+ 1 file changed, 9 insertions(+), 23 deletions(-)
+
+diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
+index 5885239cc1f85..d75a4ce7d12ae 100644
+--- a/drivers/md/dm-integrity.c
++++ b/drivers/md/dm-integrity.c
+@@ -6,6 +6,8 @@
+ * This file is released under the GPL.
+ */
+
++#include "dm-bio-record.h"
++
+ #include <linux/compiler.h>
+ #include <linux/module.h>
+ #include <linux/device-mapper.h>
+@@ -276,11 +278,7 @@ struct dm_integrity_io {
+
+ struct completion *completion;
+
+- struct gendisk *orig_bi_disk;
+- u8 orig_bi_partno;
+- bio_end_io_t *orig_bi_end_io;
+- struct bio_integrity_payload *orig_bi_integrity;
+- struct bvec_iter orig_bi_iter;
++ struct dm_bio_details bio_details;
+ };
+
+ struct journal_completion {
+@@ -1249,14 +1247,9 @@ static void integrity_end_io(struct bio *bio)
+ {
+ struct dm_integrity_io *dio = dm_per_bio_data(bio, sizeof(struct dm_integrity_io));
+
+- bio->bi_iter = dio->orig_bi_iter;
+- bio->bi_disk = dio->orig_bi_disk;
+- bio->bi_partno = dio->orig_bi_partno;
+- if (dio->orig_bi_integrity) {
+- bio->bi_integrity = dio->orig_bi_integrity;
++ dm_bio_restore(&dio->bio_details, bio);
++ if (bio->bi_integrity)
+ bio->bi_opf |= REQ_INTEGRITY;
+- }
+- bio->bi_end_io = dio->orig_bi_end_io;
+
+ if (dio->completion)
+ complete(dio->completion);
+@@ -1336,7 +1329,7 @@ static void integrity_metadata(struct work_struct *w)
+ if (!checksums)
+ checksums = checksums_onstack;
+
+- __bio_for_each_segment(bv, bio, iter, dio->orig_bi_iter) {
++ __bio_for_each_segment(bv, bio, iter, dio->bio_details.bi_iter) {
+ unsigned pos;
+ char *mem, *checksums_ptr;
+
+@@ -1380,7 +1373,7 @@ static void integrity_metadata(struct work_struct *w)
+ if (likely(checksums != checksums_onstack))
+ kfree(checksums);
+ } else {
+- struct bio_integrity_payload *bip = dio->orig_bi_integrity;
++ struct bio_integrity_payload *bip = dio->bio_details.bi_integrity;
+
+ if (bip) {
+ struct bio_vec biv;
+@@ -1784,20 +1777,13 @@ static void dm_integrity_map_continue(struct dm_integrity_io *dio, bool from_map
+ } else
+ dio->completion = NULL;
+
+- dio->orig_bi_iter = bio->bi_iter;
+-
+- dio->orig_bi_disk = bio->bi_disk;
+- dio->orig_bi_partno = bio->bi_partno;
++ dm_bio_record(&dio->bio_details, bio);
+ bio_set_dev(bio, ic->dev->bdev);
+-
+- dio->orig_bi_integrity = bio_integrity(bio);
+ bio->bi_integrity = NULL;
+ bio->bi_opf &= ~REQ_INTEGRITY;
+-
+- dio->orig_bi_end_io = bio->bi_end_io;
+ bio->bi_end_io = integrity_end_io;
+-
+ bio->bi_iter.bi_size = dio->range.n_sectors << SECTOR_SHIFT;
++
+ generic_make_request(bio);
+
+ if (need_sync_io) {
+--
+2.20.1
+
--- /dev/null
+From 4f5edcd28212d7b3e7d92364ce4950cdf8a515ad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 26 Feb 2020 13:45:10 +0800
+Subject: drivers/perf: arm_pmu_acpi: Fix incorrect checking of gicc pointer
+
+From: luanshi <zhangliguang@linux.alibaba.com>
+
+[ Upstream commit 3ba52ad55b533760a1f65836aa0ec9d35e36bb4f ]
+
+Fix bogus NULL checks on the return value of acpi_cpu_get_madt_gicc()
+by checking for a 0 'gicc->performance_interrupt' value instead.
+
+Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/perf/arm_pmu_acpi.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
+index 0f197516d7089..9a6f7f822566f 100644
+--- a/drivers/perf/arm_pmu_acpi.c
++++ b/drivers/perf/arm_pmu_acpi.c
+@@ -27,8 +27,6 @@ static int arm_pmu_acpi_register_irq(int cpu)
+ int gsi, trigger;
+
+ gicc = acpi_cpu_get_madt_gicc(cpu);
+- if (WARN_ON(!gicc))
+- return -EINVAL;
+
+ gsi = gicc->performance_interrupt;
+
+@@ -67,11 +65,10 @@ static void arm_pmu_acpi_unregister_irq(int cpu)
+ int gsi;
+
+ gicc = acpi_cpu_get_madt_gicc(cpu);
+- if (!gicc)
+- return;
+
+ gsi = gicc->performance_interrupt;
+- acpi_unregister_gsi(gsi);
++ if (gsi)
++ acpi_unregister_gsi(gsi);
+ }
+
+ static int arm_pmu_acpi_parse_irqs(void)
+--
+2.20.1
+
--- /dev/null
+From 9115f1c00f4d8fcfb7cfd6843ac0c5f96cfdbaf2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Feb 2020 11:16:14 -0500
+Subject: drm/amd/display: Clear link settings on MST disable connector
+
+From: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
+
+[ Upstream commit 5ac7fd2f597b88ee81f4748ee50cab06192a8dc3 ]
+
+[Why]
+If we have a single MST display and we disconnect it, we dont disable that
+link. This causes the old link settings to still exist
+
+Now on a replug for MST we think its a link loss and will try to reallocate
+mst payload which will fail, throwing warning below.
+
+[ 129.374192] [drm] Failed to updateMST allocation table forpipe idx:0
+[ 129.374206] ------------[ cut here ]------------
+[ 129.374284] WARNING: CPU: 14 PID: 1710 at
+drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/core/dc_link.c:3153
+dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]
+
+[ 129.374285] Modules linked in: amdgpu(OE) amd_iommu_v2 gpu_sched ttm
+drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt
+binfmt_misc nls_iso8859_1 edac_mce_amd snd_hda_codec_realtek
+snd_hda_codec_generic ledtrig_audio kvm snd_hda_codec_hdmi snd_hda_intel
+snd_intel_nhlt snd_hda_codec irqbypass snd_hda_core snd_hwdep snd_pcm
+snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul snd_seq
+crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer snd aesni_intel
+eeepc_wmi crypto_simd asus_wmi joydev cryptd sparse_keymap input_leds
+soundcore video glue_helper wmi_bmof mxm_wmi k10temp ccp mac_hid
+sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4
+hid_generic usbhid hid igb i2c_algo_bit ahci dca i2c_piix4 libahci
+gpio_amdpt wmi gpio_generic
+
+[ 129.374318] CPU: 14 PID: 1710 Comm: kworker/14:2 Tainted: G W OE 5.4.0-rc7bhawan+ #480
+[ 129.374318] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0515 03/30/2017
+[ 129.374397] Workqueue: events dm_irq_work_func [amdgpu]
+[ 129.374468] RIP: 0010:dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu]
+[ 129.374470] Code: 52 20 e8 1c 63 ad f4 48 8b 5d d0 65 48 33 1c 25 28 00
+00 00 b8 01 00 00 00 75 16 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3
+<0f> 0b e9 fa fe ff ff e8 ed 5b d6 f3 41 0f b6 b6 c4 02 00 00 48 c7
+[ 129.374471] RSP: 0018:ffff9f9141e7fcc0 EFLAGS: 00010246
+[ 129.374472] RAX: 0000000000000000 RBX: ffff91ef0762f800 RCX: 0000000000000000
+[ 129.374473] RDX: 0000000000000005 RSI: ffffffffc0c4a988 RDI: 0000000000000004
+[ 129.374474] RBP: ffff9f9141e7fd10 R08: 0000000000000005 R09: 0000000000000000
+[ 129.374475] R10: 0000000000000002 R11: 0000000000000001 R12: ffff91eebd510c00
+[ 129.374475] R13: ffff91eebd510e58 R14: ffff91ef052c01b8 R15: 0000000000000006
+[ 129.374476] FS: 0000000000000000(0000) GS:ffff91ef0ef80000(0000) knlGS:0000000000000000
+[ 129.374477] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 129.374478] CR2: 000055623ea01d50 CR3: 0000000408a8c000 CR4: 00000000003406e0
+[ 129.374479] Call Trace:
+[ 129.374550] dc_link_reallocate_mst_payload+0x12e/0x150 [amdgpu]
+[ 129.374617] dc_link_handle_hpd_rx_irq+0x6d4/0x6e0 [amdgpu]
+[ 129.374693] handle_hpd_rx_irq+0x77/0x310 [amdgpu]
+[ 129.374768] dm_irq_work_func+0x53/0x70 [amdgpu]
+[ 129.374774] process_one_work+0x1fd/0x3f0
+[ 129.374776] worker_thread+0x255/0x410
+[ 129.374778] kthread+0x121/0x140
+[ 129.374780] ? process_one_work+0x3f0/0x3f0
+[ 129.374781] ? kthread_park+0x90/0x90
+[ 129.374785] ret_from_fork+0x22/0x40
+
+[How]
+when we disable MST we should clear the cur link settings (lane_count=0 is
+good enough). This will cause us to not reallocate payloads earlier than
+expected and not throw the warning
+
+Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
+Reviewed-by: Hersen Wu <hersenxs.wu@amd.com>
+Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+index c85bea70d9652..ad9561853d8e3 100644
+--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+@@ -419,6 +419,7 @@ static void dm_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
+ dc_link_remove_remote_sink(aconnector->dc_link, aconnector->dc_sink);
+ dc_sink_release(aconnector->dc_sink);
+ aconnector->dc_sink = NULL;
++ aconnector->dc_link->cur_link_settings.lane_count = 0;
+ }
+
+ drm_connector_unregister(connector);
+--
+2.20.1
+
--- /dev/null
+From 5b14ea251b917f8726e08eb5d240343f8aac7c33 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 12:26:19 -0500
+Subject: drm/amd/display: fix dcc swath size calculations on dcn1
+
+From: Josip Pavic <Josip.Pavic@amd.com>
+
+[ Upstream commit a0275dfc82c9034eefbeffd556cca6dd239d7925 ]
+
+[Why]
+Swath sizes are being calculated incorrectly. The horizontal swath size
+should be the product of block height, viewport width, and bytes per
+element, but the calculation uses viewport height instead of width. The
+vertical swath size is similarly incorrectly calculated. The effect of
+this is that we report the wrong DCC caps.
+
+[How]
+Use viewport width in the horizontal swath size calculation and viewport
+height in the vertical swath size calculation.
+
+Signed-off-by: Josip Pavic <Josip.Pavic@amd.com>
+Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
+Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
+index 1ea91e153d3a6..c1adac888fd83 100644
+--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c
+@@ -684,8 +684,8 @@ static void hubbub1_det_request_size(
+
+ hubbub1_get_blk256_size(&blk256_width, &blk256_height, bpe);
+
+- swath_bytes_horz_wc = height * blk256_height * bpe;
+- swath_bytes_vert_wc = width * blk256_width * bpe;
++ swath_bytes_horz_wc = width * blk256_height * bpe;
++ swath_bytes_vert_wc = height * blk256_width * bpe;
+
+ *req128_horz_wc = (2 * swath_bytes_horz_wc <= detile_buf_size) ?
+ false : /* full 256B request */
+--
+2.20.1
+
--- /dev/null
+From 0f73ed05ccba4b7b57ae6a99b9f987cae840226c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Feb 2020 13:30:12 +0100
+Subject: drm/exynos: dsi: fix workaround for the legacy clock name
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+[ Upstream commit c0fd99d659ba5582e09625c7a985d63fc2ca74b5 ]
+
+Writing to the built-in strings arrays doesn't work if driver is loaded
+as kernel module. This is also considered as a bad pattern. Fix this by
+adding a call to clk_get() with legacy clock name. This fixes following
+kernel oops if driver is loaded as module:
+
+Unable to handle kernel paging request at virtual address bf047978
+ pgd = (ptrval)
+ [bf047978] *pgd=59344811, *pte=5903c6df, *ppte=5903c65f
+ Internal error: Oops: 80f [#1] SMP ARM
+ Modules linked in: mc exynosdrm(+) analogix_dp rtc_s3c exynos_ppmu i2c_gpio
+ CPU: 1 PID: 212 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219 #326
+ videodev: Linux video capture interface: v2.00
+ Hardware name: Samsung Exynos (Flattened Device Tree)
+ PC is at exynos_dsi_probe+0x1f0/0x384 [exynosdrm]
+ LR is at exynos_dsi_probe+0x1dc/0x384 [exynosdrm]
+ ...
+ Process systemd-udevd (pid: 212, stack limit = 0x(ptrval))
+ ...
+ [<bf03cf14>] (exynos_dsi_probe [exynosdrm]) from [<c09b1ca0>] (platform_drv_probe+0x6c/0xa4)
+ [<c09b1ca0>] (platform_drv_probe) from [<c09afcb8>] (really_probe+0x210/0x350)
+ [<c09afcb8>] (really_probe) from [<c09aff74>] (driver_probe_device+0x60/0x1a0)
+ [<c09aff74>] (driver_probe_device) from [<c09b0254>] (device_driver_attach+0x58/0x60)
+ [<c09b0254>] (device_driver_attach) from [<c09b02dc>] (__driver_attach+0x80/0xbc)
+ [<c09b02dc>] (__driver_attach) from [<c09ade00>] (bus_for_each_dev+0x68/0xb4)
+ [<c09ade00>] (bus_for_each_dev) from [<c09aefd8>] (bus_add_driver+0x130/0x1e8)
+ [<c09aefd8>] (bus_add_driver) from [<c09b0d64>] (driver_register+0x78/0x110)
+ [<c09b0d64>] (driver_register) from [<bf038558>] (exynos_drm_init+0xe8/0x11c [exynosdrm])
+ [<bf038558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220)
+ [<c0302fa8>] (do_one_initcall) from [<c03dd02c>] (do_init_module+0x60/0x210)
+ [<c03dd02c>] (do_init_module) from [<c03dbf44>] (load_module+0x1c0c/0x2310)
+ [<c03dbf44>] (load_module) from [<c03dc85c>] (sys_finit_module+0xac/0xbc)
+ [<c03dc85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54)
+ Exception stack(0xd979bfa8 to 0xd979bff0)
+ ...
+ ---[ end trace db16efe05faab470 ]---
+
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
+Signed-off-by: Inki Dae <inki.dae@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+index b23adce9d00a7..8d776070913da 100644
+--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
++++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+@@ -1737,9 +1737,10 @@ static int exynos_dsi_probe(struct platform_device *pdev)
+ dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
+ if (IS_ERR(dsi->clks[i])) {
+ if (strcmp(clk_names[i], "sclk_mipi") == 0) {
+- strcpy(clk_names[i], OLD_SCLK_MIPI_CLK_NAME);
+- i--;
+- continue;
++ dsi->clks[i] = devm_clk_get(dev,
++ OLD_SCLK_MIPI_CLK_NAME);
++ if (!IS_ERR(dsi->clks[i]))
++ continue;
+ }
+
+ dev_info(dev, "failed to get the clock: %s\n",
+--
+2.20.1
+
--- /dev/null
+From f997466cf65209725469f90894c29575126caa6f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Feb 2020 08:06:37 +0100
+Subject: drm/exynos: dsi: propagate error value and silence meaningless
+ warning
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+[ Upstream commit 0a9d1e3f3f038785ebc72d53f1c409d07f6b4ff5 ]
+
+Properly propagate error value from devm_regulator_bulk_get() and don't
+confuse user with meaningless warning about failure in getting regulators
+in case of deferred probe.
+
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Inki Dae <inki.dae@samsung.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+index 781b82c2c579b..b23adce9d00a7 100644
+--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
++++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+@@ -1722,8 +1722,9 @@ static int exynos_dsi_probe(struct platform_device *pdev)
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
+ dsi->supplies);
+ if (ret) {
+- dev_info(dev, "failed to get regulators: %d\n", ret);
+- return -EPROBE_DEFER;
++ if (ret != -EPROBE_DEFER)
++ dev_info(dev, "failed to get regulators: %d\n", ret);
++ return ret;
+ }
+
+ dsi->clks = devm_kcalloc(dev,
+--
+2.20.1
+
--- /dev/null
+From 98e5373cd2ace35da755da094055da7821dd78e6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 15:23:51 +1100
+Subject: drm/mediatek: Find the cursor plane instead of hard coding it
+
+From: Evan Benn <evanbenn@chromium.org>
+
+[ Upstream commit 318caac7c81cdf5806df30c3d72385659a5f0f53 ]
+
+The cursor and primary planes were hard coded.
+Now search for them for passing to drm_crtc_init_with_planes
+
+Signed-off-by: Evan Benn <evanbenn@chromium.org>
+Reviewed-by: Sean Paul <seanpaul@chromium.org>
+Signed-off-by: CK Hu <ck.hu@mediatek.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 ++++++++++++------
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+index b86ee7d25af36..eac9caf322f90 100644
+--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
++++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+@@ -506,10 +506,18 @@ static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
+
+ static int mtk_drm_crtc_init(struct drm_device *drm,
+ struct mtk_drm_crtc *mtk_crtc,
+- struct drm_plane *primary,
+- struct drm_plane *cursor, unsigned int pipe)
++ unsigned int pipe)
+ {
+- int ret;
++ struct drm_plane *primary = NULL;
++ struct drm_plane *cursor = NULL;
++ int i, ret;
++
++ for (i = 0; i < mtk_crtc->layer_nr; i++) {
++ if (mtk_crtc->planes[i].type == DRM_PLANE_TYPE_PRIMARY)
++ primary = &mtk_crtc->planes[i];
++ else if (mtk_crtc->planes[i].type == DRM_PLANE_TYPE_CURSOR)
++ cursor = &mtk_crtc->planes[i];
++ }
+
+ ret = drm_crtc_init_with_planes(drm, &mtk_crtc->base, primary, cursor,
+ &mtk_crtc_funcs, NULL);
+@@ -622,9 +630,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
+ goto unprepare;
+ }
+
+- ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, &mtk_crtc->planes[0],
+- mtk_crtc->layer_nr > 1 ? &mtk_crtc->planes[1] :
+- NULL, pipe);
++ ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, pipe);
+ if (ret < 0)
+ goto unprepare;
+ drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
+--
+2.20.1
+
--- /dev/null
+From 54489a90b83ae1b6725a482a779fd615587e7fdc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 23:13:11 +0100
+Subject: parse-maintainers: Mark as executable
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+
+[ Upstream commit 611d61f9ac99dc9e1494473fb90117a960a89dfa ]
+
+This makes the script more convenient to run.
+
+Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/parse-maintainers.pl | 0
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ mode change 100644 => 100755 scripts/parse-maintainers.pl
+
+diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
+old mode 100644
+new mode 100755
+--
+2.20.1
+
--- /dev/null
+From e2d4499a317a1b1c6fe96983cf6970ba86b6ed75 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Feb 2020 17:01:32 +0530
+Subject: powerpc: Include .BTF section
+
+From: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+
+[ Upstream commit cb0cc635c7a9fa8a3a0f75d4d896721819c63add ]
+
+Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld:
+ ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed in section `.BTF'
+
+Include .BTF section in vmlinux explicitly to fix the same.
+
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20200220113132.857132-1-naveen.n.rao@linux.vnet.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
+index fd35eddf32669..d081d726ca8ea 100644
+--- a/arch/powerpc/kernel/vmlinux.lds.S
++++ b/arch/powerpc/kernel/vmlinux.lds.S
+@@ -322,6 +322,12 @@ SECTIONS
+ *(.branch_lt)
+ }
+
++#ifdef CONFIG_DEBUG_INFO_BTF
++ .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) {
++ *(.BTF)
++ }
++#endif
++
+ .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
+ __start_opd = .;
+ KEEP(*(.opd))
+--
+2.20.1
+
--- /dev/null
+From a71c4cd37be388868bfee58b7adeeda862ad86fc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 10:47:54 +0800
+Subject: riscv: avoid the PIC offset of static percpu data in module beyond 2G
+ limits
+
+From: Vincent Chen <vincent.chen@sifive.com>
+
+[ Upstream commit 0cff8bff7af886af0923d5c91776cd51603e531f ]
+
+The compiler uses the PIC-relative method to access static variables
+instead of GOT when the code model is PIC. Therefore, the limitation of
+the access range from the instruction to the symbol address is +-2GB.
+Under this circumstance, the kernel cannot load a kernel module if this
+module has static per-CPU symbols declared by DEFINE_PER_CPU(). The reason
+is that kernel relocates the .data..percpu section of the kernel module to
+the end of kernel's .data..percpu. Hence, the distance between the per-CPU
+symbols and the instruction will exceed the 2GB limits. To solve this
+problem, the kernel should place the loaded module in the memory area
+[&_end-2G, VMALLOC_END].
+
+Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
+Suggested-by: Alexandre Ghiti <alex@ghiti.fr>
+Suggested-by: Anup Patel <anup@brainfault.org>
+Tested-by: Alexandre Ghiti <alex@ghiti.fr>
+Tested-by: Carlos de Paula <me@carlosedp.com>
+Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/riscv/kernel/module.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
+index 7dd308129b40f..7c012ad1d7ede 100644
+--- a/arch/riscv/kernel/module.c
++++ b/arch/riscv/kernel/module.c
+@@ -16,6 +16,10 @@
+ #include <linux/err.h>
+ #include <linux/errno.h>
+ #include <linux/moduleloader.h>
++#include <linux/vmalloc.h>
++#include <linux/sizes.h>
++#include <asm/pgtable.h>
++#include <asm/sections.h>
+
+ static int apply_r_riscv_32_rela(struct module *me, u32 *location, Elf_Addr v)
+ {
+@@ -394,3 +398,15 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
+
+ return 0;
+ }
++
++#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
++#define VMALLOC_MODULE_START \
++ max(PFN_ALIGN((unsigned long)&_end - SZ_2G), VMALLOC_START)
++void *module_alloc(unsigned long size)
++{
++ return __vmalloc_node_range(size, 1, VMALLOC_MODULE_START,
++ VMALLOC_END, GFP_KERNEL,
++ PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
++ __builtin_return_address(0));
++}
++#endif
+--
+2.20.1
+
--- /dev/null
+drm-mediatek-find-the-cursor-plane-instead-of-hard-c.patch
+spi-qup-call-spi_qup_pm_resume_runtime-before-suspen.patch
+powerpc-include-.btf-section.patch
+arm-dts-dra7-add-dma-ranges-property-to-pcie-rc-dt-n.patch
+spi-pxa2xx-add-cs-control-clock-quirk.patch
+spi-zynqmp-remove-entry-that-causes-a-cs-glitch.patch
+drm-exynos-dsi-propagate-error-value-and-silence-mea.patch
+drm-exynos-dsi-fix-workaround-for-the-legacy-clock-n.patch
+drivers-perf-arm_pmu_acpi-fix-incorrect-checking-of-.patch
+altera-stapl-altera_get_note-prevent-write-beyond-en.patch
+dm-bio-record-save-restore-bi_end_io-and-bi_integrit.patch
+dm-integrity-use-dm_bio_record-and-dm_bio_restore.patch
+riscv-avoid-the-pic-offset-of-static-percpu-data-in-.patch
+drm-amd-display-clear-link-settings-on-mst-disable-c.patch
+drm-amd-display-fix-dcc-swath-size-calculations-on-d.patch
+xenbus-req-body-should-be-updated-before-req-state.patch
+xenbus-req-err-should-be-updated-before-req-state.patch
+block-bfq-fix-overwrite-of-bfq_group-pointer-in-bfq_.patch
+parse-maintainers-mark-as-executable.patch
--- /dev/null
+From 92a8a78bf2b31fa12c462fb7cce57643de7e75d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Feb 2020 14:37:00 -0800
+Subject: spi: pxa2xx: Add CS control clock quirk
+
+From: Evan Green <evgreen@chromium.org>
+
+[ Upstream commit 683f65ded66a9a7ff01ed7280804d2132ebfdf7e ]
+
+In some circumstances on Intel LPSS controllers, toggling the LPSS
+CS control register doesn't actually cause the CS line to toggle.
+This seems to be failure of dynamic clock gating that occurs after
+going through a suspend/resume transition, where the controller
+is sent through a reset transition. This ruins SPI transactions
+that either rely on delay_usecs, or toggle the CS line without
+sending data.
+
+Whenever CS is toggled, momentarily set the clock gating register
+to "Force On" to poke the controller into acting on CS.
+
+Signed-off-by: Rajat Jain <rajatja@google.com>
+Signed-off-by: Evan Green <evgreen@chromium.org>
+Link: https://lore.kernel.org/r/20200211223700.110252-1-rajatja@google.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-pxa2xx.c | 23 +++++++++++++++++++++++
+ 1 file changed, 23 insertions(+)
+
+diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
+index 525388126e260..e4482823d8d75 100644
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -76,6 +76,10 @@ MODULE_ALIAS("platform:pxa2xx-spi");
+ #define LPSS_CAPS_CS_EN_SHIFT 9
+ #define LPSS_CAPS_CS_EN_MASK (0xf << LPSS_CAPS_CS_EN_SHIFT)
+
++#define LPSS_PRIV_CLOCK_GATE 0x38
++#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK 0x3
++#define LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON 0x3
++
+ struct lpss_config {
+ /* LPSS offset from drv_data->ioaddr */
+ unsigned offset;
+@@ -92,6 +96,8 @@ struct lpss_config {
+ unsigned cs_sel_shift;
+ unsigned cs_sel_mask;
+ unsigned cs_num;
++ /* Quirks */
++ unsigned cs_clk_stays_gated : 1;
+ };
+
+ /* Keep these sorted with enum pxa_ssp_type */
+@@ -162,6 +168,7 @@ static const struct lpss_config lpss_platforms[] = {
+ .tx_threshold_hi = 56,
+ .cs_sel_shift = 8,
+ .cs_sel_mask = 3 << 8,
++ .cs_clk_stays_gated = true,
+ },
+ };
+
+@@ -389,6 +396,22 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable)
+ else
+ value |= LPSS_CS_CONTROL_CS_HIGH;
+ __lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value);
++ if (config->cs_clk_stays_gated) {
++ u32 clkgate;
++
++ /*
++ * Changing CS alone when dynamic clock gating is on won't
++ * actually flip CS at that time. This ruins SPI transfers
++ * that specify delays, or have no data. Toggle the clock mode
++ * to force on briefly to poke the CS pin to move.
++ */
++ clkgate = __lpss_ssp_read_priv(drv_data, LPSS_PRIV_CLOCK_GATE);
++ value = (clkgate & ~LPSS_PRIV_CLOCK_GATE_CLK_CTL_MASK) |
++ LPSS_PRIV_CLOCK_GATE_CLK_CTL_FORCE_ON;
++
++ __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, value);
++ __lpss_ssp_write_priv(drv_data, LPSS_PRIV_CLOCK_GATE, clkgate);
++ }
+ }
+
+ static void cs_assert(struct spi_device *spi)
+--
+2.20.1
+
--- /dev/null
+From 2fa2f72f913f4962e7a672436512e8a31d2abae4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 14 Feb 2020 13:13:40 +0530
+Subject: spi: qup: call spi_qup_pm_resume_runtime before suspending
+
+From: Yuji Sasaki <sasakiy@chromium.org>
+
+[ Upstream commit 136b5cd2e2f97581ae560cff0db2a3b5369112da ]
+
+spi_qup_suspend() will cause synchronous external abort when
+runtime suspend is enabled and applied, as it tries to
+access SPI controller register while clock is already disabled
+in spi_qup_pm_suspend_runtime().
+
+Signed-off-by: Yuji sasaki <sasakiy@chromium.org>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Link: https://lore.kernel.org/r/20200214074340.2286170-1-vkoul@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-qup.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
+index 974a8ce58b68b..cb74fd1af2053 100644
+--- a/drivers/spi/spi-qup.c
++++ b/drivers/spi/spi-qup.c
+@@ -1190,6 +1190,11 @@ static int spi_qup_suspend(struct device *device)
+ struct spi_qup *controller = spi_master_get_devdata(master);
+ int ret;
+
++ if (pm_runtime_suspended(device)) {
++ ret = spi_qup_pm_resume_runtime(device);
++ if (ret)
++ return ret;
++ }
+ ret = spi_master_suspend(master);
+ if (ret)
+ return ret;
+@@ -1198,10 +1203,8 @@ static int spi_qup_suspend(struct device *device)
+ if (ret)
+ return ret;
+
+- if (!pm_runtime_suspended(device)) {
+- clk_disable_unprepare(controller->cclk);
+- clk_disable_unprepare(controller->iclk);
+- }
++ clk_disable_unprepare(controller->cclk);
++ clk_disable_unprepare(controller->iclk);
+ return 0;
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 3e2afd1d8c3968a1cbd9d68a5bf3457730f4094c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 24 Feb 2020 17:26:43 +0100
+Subject: spi/zynqmp: remove entry that causes a cs glitch
+
+From: Thommy Jakobsson <thommyj@gmail.com>
+
+[ Upstream commit 5dd8304981ecffa77bb72b1c57c4be5dfe6cfae9 ]
+
+In the public interface for chipselect, there is always an entry
+commented as "Dummy generic FIFO entry" pushed down to the fifo right
+after the activate/deactivate command. The dummy entry is 0x0,
+irregardless if the intention was to activate or deactive the cs. This
+causes the cs line to glitch rather than beeing activated in the case
+when there was an activate command.
+
+This has been observed on oscilloscope, and have caused problems for at
+least one specific flash device type connected to the qspi port. After
+the change the glitch is gone and cs goes active when intended.
+
+The reason why this worked before (except for the glitch) was because
+when sending the actual data, the CS bits are once again set. Since
+most flashes uses mode 0, there is always a half clk period anyway for
+cs to clk active setup time. If someone would rely on timing from a
+chip_select call to a transfer_one, it would fail though.
+
+It is unknown why the dummy entry was there in the first place, git log
+seems to be of no help in this case. The reference manual gives no
+indication of the necessity of this. In fact the lower 8 bits are a
+setup (or hold in case of deactivate) time expressed in cycles. So this
+should not be needed to fulfill any setup/hold timings.
+
+Signed-off-by: Thommy Jakobsson <thommyj@gmail.com>
+Reviewed-by: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>
+Link: https://lore.kernel.org/r/20200224162643.29102-1-thommyj@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-zynqmp-gqspi.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
+index cc4d310334943..f2848c59b0b8e 100644
+--- a/drivers/spi/spi-zynqmp-gqspi.c
++++ b/drivers/spi/spi-zynqmp-gqspi.c
+@@ -403,9 +403,6 @@ static void zynqmp_qspi_chipselect(struct spi_device *qspi, bool is_high)
+
+ zynqmp_gqspi_write(xqspi, GQSPI_GEN_FIFO_OFST, genfifoentry);
+
+- /* Dummy generic FIFO entry */
+- zynqmp_gqspi_write(xqspi, GQSPI_GEN_FIFO_OFST, 0x0);
+-
+ /* Manually start the generic FIFO command */
+ zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST,
+ zynqmp_gqspi_read(xqspi, GQSPI_CONFIG_OFST) |
+--
+2.20.1
+
--- /dev/null
+From b3ca1c64ce3880e0dffe7f2ddfc2d46652ad36a8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 14:14:22 -0800
+Subject: xenbus: req->body should be updated before req->state
+
+From: Dongli Zhang <dongli.zhang@oracle.com>
+
+[ Upstream commit 1b6a51e86cce38cf4d48ce9c242120283ae2f603 ]
+
+The req->body should be updated before req->state is updated and the
+order should be guaranteed by a barrier.
+
+Otherwise, read_reply() might return req->body = NULL.
+
+Below is sample callstack when the issue is reproduced on purpose by
+reordering the updates of req->body and req->state and adding delay in
+code between updates of req->state and req->body.
+
+[ 22.356105] general protection fault: 0000 [#1] SMP PTI
+[ 22.361185] CPU: 2 PID: 52 Comm: xenwatch Not tainted 5.5.0xen+ #6
+[ 22.366727] Hardware name: Xen HVM domU, BIOS ...
+[ 22.372245] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60
+... ...
+[ 22.392163] RSP: 0018:ffffb2d64023fdf0 EFLAGS: 00010246
+[ 22.395933] RAX: 0000000000000000 RBX: 75746e7562755f6d RCX: 0000000000000000
+[ 22.400871] RDX: 0000000000000000 RSI: ffffb2d64023fdfc RDI: 75746e7562755f6d
+[ 22.405874] RBP: 0000000000000000 R08: 00000000000001e8 R09: 0000000000cdcdcd
+[ 22.410945] R10: ffffb2d6402ffe00 R11: ffff9d95395eaeb0 R12: ffff9d9535935000
+[ 22.417613] R13: ffff9d9526d4a000 R14: ffff9d9526f4f340 R15: ffff9d9537654000
+[ 22.423726] FS: 0000000000000000(0000) GS:ffff9d953bc80000(0000) knlGS:0000000000000000
+[ 22.429898] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 22.434342] CR2: 000000c4206a9000 CR3: 00000001ea3fc002 CR4: 00000000001606e0
+[ 22.439645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 22.444941] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 22.450342] Call Trace:
+[ 22.452509] simple_strtoull+0x27/0x70
+[ 22.455572] xenbus_transaction_start+0x31/0x50
+[ 22.459104] netback_changed+0x76c/0xcc1 [xen_netfront]
+[ 22.463279] ? find_watch+0x40/0x40
+[ 22.466156] xenwatch_thread+0xb4/0x150
+[ 22.469309] ? wait_woken+0x80/0x80
+[ 22.472198] kthread+0x10e/0x130
+[ 22.474925] ? kthread_park+0x80/0x80
+[ 22.477946] ret_from_fork+0x35/0x40
+[ 22.480968] Modules linked in: xen_kbdfront xen_fbfront(+) xen_netfront xen_blkfront
+[ 22.486783] ---[ end trace a9222030a747c3f7 ]---
+[ 22.490424] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60
+
+The virt_rmb() is added in the 'true' path of test_reply(). The "while"
+is changed to "do while" so that test_reply() is used as a read memory
+barrier.
+
+Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
+Link: https://lore.kernel.org/r/20200303221423.21962-1-dongli.zhang@oracle.com
+Reviewed-by: Julien Grall <jgrall@amazon.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/xen/xenbus/xenbus_comms.c | 2 ++
+ drivers/xen/xenbus/xenbus_xs.c | 9 ++++++---
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
+index d239fc3c5e3de..852ed161fc2a7 100644
+--- a/drivers/xen/xenbus/xenbus_comms.c
++++ b/drivers/xen/xenbus/xenbus_comms.c
+@@ -313,6 +313,8 @@ static int process_msg(void)
+ req->msg.type = state.msg.type;
+ req->msg.len = state.msg.len;
+ req->body = state.body;
++ /* write body, then update state */
++ virt_wmb();
+ req->state = xb_req_state_got_reply;
+ req->cb(req);
+ } else
+diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
+index ddc18da61834e..3a06eb699f333 100644
+--- a/drivers/xen/xenbus/xenbus_xs.c
++++ b/drivers/xen/xenbus/xenbus_xs.c
+@@ -191,8 +191,11 @@ static bool xenbus_ok(void)
+
+ static bool test_reply(struct xb_req_data *req)
+ {
+- if (req->state == xb_req_state_got_reply || !xenbus_ok())
++ if (req->state == xb_req_state_got_reply || !xenbus_ok()) {
++ /* read req->state before all other fields */
++ virt_rmb();
+ return true;
++ }
+
+ /* Make sure to reread req->state each time. */
+ barrier();
+@@ -202,7 +205,7 @@ static bool test_reply(struct xb_req_data *req)
+
+ static void *read_reply(struct xb_req_data *req)
+ {
+- while (req->state != xb_req_state_got_reply) {
++ do {
+ wait_event(req->wq, test_reply(req));
+
+ if (!xenbus_ok())
+@@ -216,7 +219,7 @@ static void *read_reply(struct xb_req_data *req)
+ if (req->err)
+ return ERR_PTR(req->err);
+
+- }
++ } while (req->state != xb_req_state_got_reply);
+
+ return req->body;
+ }
+--
+2.20.1
+
--- /dev/null
+From 8246166746359d94b5bda1c8f04b20a5fc637bfb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 14:14:23 -0800
+Subject: xenbus: req->err should be updated before req->state
+
+From: Dongli Zhang <dongli.zhang@oracle.com>
+
+[ Upstream commit 8130b9d5b5abf26f9927b487c15319a187775f34 ]
+
+This patch adds the barrier to guarantee that req->err is always updated
+before req->state.
+
+Otherwise, read_reply() would not return ERR_PTR(req->err) but
+req->body, when process_writes()->xb_write() is failed.
+
+Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
+Link: https://lore.kernel.org/r/20200303221423.21962-2-dongli.zhang@oracle.com
+Reviewed-by: Julien Grall <jgrall@amazon.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/xen/xenbus/xenbus_comms.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
+index 852ed161fc2a7..eb5151fc8efab 100644
+--- a/drivers/xen/xenbus/xenbus_comms.c
++++ b/drivers/xen/xenbus/xenbus_comms.c
+@@ -397,6 +397,8 @@ static int process_writes(void)
+ if (state.req->state == xb_req_state_aborted)
+ kfree(state.req);
+ else {
++ /* write err, then update state */
++ virt_wmb();
+ state.req->state = xb_req_state_got_reply;
+ wake_up(&state.req->wq);
+ }
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
