--- /dev/null
+From f389a52799a490a4cfa70b03dfda75545ce00350 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 00:15:24 +0100
+Subject: ACPI: EC: Do not clear boot_ec_is_ecdt in acpi_ec_add()
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+[ Upstream commit 65a691f5f8f0bb63d6a82eec7b0ffd193d8d8a5f ]
+
+The reason for clearing boot_ec_is_ecdt in acpi_ec_add() (if a
+PNP0C09 device object matching the ECDT boot EC had been found in
+the namespace) was to cause acpi_ec_ecdt_start() to return early,
+but since the latter does not look at boot_ec_is_ecdt any more,
+acpi_ec_add() need not clear it.
+
+Moreover, doing that may be confusing as it may cause "DSDT" to be
+printed instead of "ECDT" in the EC initialization completion
+message, so stop doing it.
+
+While at it, split the EC initialization completion message into
+two messages, one regarding the boot EC and another one printed
+regardless of whether or not the EC at hand is the boot one.
+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/acpi/ec.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
+index d1f1cf5d4bf08..3385be8b057c8 100644
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -1641,7 +1641,6 @@ static int acpi_ec_add(struct acpi_device *device)
+
+ if (boot_ec && ec->command_addr == boot_ec->command_addr &&
+ ec->data_addr == boot_ec->data_addr) {
+- boot_ec_is_ecdt = false;
+ /*
+ * Trust PNP0C09 namespace location rather than
+ * ECDT ID. But trust ECDT GPE rather than _GPE
+@@ -1661,9 +1660,12 @@ static int acpi_ec_add(struct acpi_device *device)
+
+ if (ec == boot_ec)
+ acpi_handle_info(boot_ec->handle,
+- "Boot %s EC used to handle transactions and events\n",
++ "Boot %s EC initialization complete\n",
+ boot_ec_is_ecdt ? "ECDT" : "DSDT");
+
++ acpi_handle_info(ec->handle,
++ "EC: Used to handle transactions and events\n");
++
+ device->driver_data = ec;
+
+ ret = !!request_region(ec->data_addr, 1, "EC data");
+--
+2.20.1
+
--- /dev/null
+From 755c7fe675b5975c15e9cd45fe70930182caafb9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 09:58:42 +0530
+Subject: arm64/mm: Hold memory hotplug lock while walking for kernel page
+ table dump
+
+From: Anshuman Khandual <anshuman.khandual@arm.com>
+
+[ Upstream commit bf2b59f60ee1fefa768d62ec6e8f4b4d9e04c691 ]
+
+The arm64 page table dump code can race with concurrent modification of the
+kernel page tables. When a leaf entries are modified concurrently, the dump
+code may log stale or inconsistent information for a VA range, but this is
+otherwise not harmful.
+
+When intermediate levels of table are freed, the dump code will continue to
+use memory which has been freed and potentially reallocated for another
+purpose. In such cases, the dump code may dereference bogus addresses,
+leading to a number of potential problems.
+
+Intermediate levels of table may by freed during memory hot-remove,
+which will be enabled by a subsequent patch. To avoid racing with
+this, take the memory hotplug lock when walking the kernel page table.
+
+Acked-by: David Hildenbrand <david@redhat.com>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Reviewed-by: Steven Price <steven.price@arm.com>
+Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/mm/ptdump_debugfs.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
+index 1f2eae3e988b6..d29d722ec3ec6 100644
+--- a/arch/arm64/mm/ptdump_debugfs.c
++++ b/arch/arm64/mm/ptdump_debugfs.c
+@@ -1,5 +1,6 @@
+ // SPDX-License-Identifier: GPL-2.0
+ #include <linux/debugfs.h>
++#include <linux/memory_hotplug.h>
+ #include <linux/seq_file.h>
+
+ #include <asm/ptdump.h>
+@@ -7,7 +8,10 @@
+ static int ptdump_show(struct seq_file *m, void *v)
+ {
+ struct ptdump_info *info = m->private;
++
++ get_online_mems();
+ ptdump_walk(m, info);
++ put_online_mems();
+ return 0;
+ }
+ DEFINE_SHOW_ATTRIBUTE(ptdump);
+--
+2.20.1
+
--- /dev/null
+From 1f667dcc2dfac6fc25c1c002ef6120c35b1f0dd3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 21:26:18 -0700
+Subject: blk-mq: Fix a recently introduced regression in
+ blk_mq_realloc_hw_ctxs()
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit d0930bb8f46b8fb4a7d429c0bf1c91b3ed00a7cf ]
+
+q->nr_hw_queues must only be updated once it is known that
+blk_mq_realloc_hw_ctxs() has succeeded. Otherwise it can happen that
+reallocation fails and that q->nr_hw_queues is larger than the number of
+allocated hardware queues. This patch fixes the following crash if
+increasing the number of hardware queues fails:
+
+BUG: KASAN: null-ptr-deref in blk_mq_map_swqueue+0x775/0x810
+Write of size 8 at addr 0000000000000118 by task check/977
+
+CPU: 3 PID: 977 Comm: check Not tainted 5.6.0-rc1-dbg+ #8
+Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
+Call Trace:
+ dump_stack+0xa5/0xe6
+ __kasan_report.cold+0x65/0x99
+ kasan_report+0x16/0x20
+ check_memory_region+0x140/0x1b0
+ memset+0x28/0x40
+ blk_mq_map_swqueue+0x775/0x810
+ blk_mq_update_nr_hw_queues+0x468/0x710
+ nullb_device_submit_queues_store+0xf7/0x1a0 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Fixes: ac0d6b926e74 ("block: Reduce the amount of memory required per request queue")
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Cc: Keith Busch <kbusch@kernel.org>
+Cc: Johannes Thumshirn <jth@kernel.org>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-mq.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/block/blk-mq.c b/block/blk-mq.c
+index d4bd9b961726a..37ff8dfb8ab9f 100644
+--- a/block/blk-mq.c
++++ b/block/blk-mq.c
+@@ -2824,7 +2824,6 @@ static void blk_mq_realloc_hw_ctxs(struct blk_mq_tag_set *set,
+ memcpy(new_hctxs, hctxs, q->nr_hw_queues *
+ sizeof(*hctxs));
+ q->queue_hw_ctx = new_hctxs;
+- q->nr_hw_queues = set->nr_hw_queues;
+ kfree(hctxs);
+ hctxs = new_hctxs;
+ }
+--
+2.20.1
+
--- /dev/null
+From 06a198402b44aadba9decab87b2e5d7c06a226e2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Mar 2020 19:18:13 +0800
+Subject: block, bfq: fix use-after-free in bfq_idle_slice_timer_body
+
+From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
+
+[ Upstream commit 2f95fa5c955d0a9987ffdc3a095e2f4e62c5f2a9 ]
+
+In bfq_idle_slice_timer func, bfqq = bfqd->in_service_queue is
+not in bfqd-lock critical section. The bfqq, which is not
+equal to NULL in bfq_idle_slice_timer, may be freed after passing
+to bfq_idle_slice_timer_body. So we will access the freed memory.
+
+In addition, considering the bfqq may be in race, we should
+firstly check whether bfqq is in service before doing something
+on it in bfq_idle_slice_timer_body func. If the bfqq in race is
+not in service, it means the bfqq has been expired through
+__bfq_bfqq_expire func, and wait_request flags has been cleared in
+__bfq_bfqd_reset_in_service func. So we do not need to re-clear the
+wait_request of bfqq which is not in service.
+
+KASAN log is given as follows:
+[13058.354613] ==================================================================
+[13058.354640] BUG: KASAN: use-after-free in bfq_idle_slice_timer+0xac/0x290
+[13058.354644] Read of size 8 at addr ffffa02cf3e63f78 by task fork13/19767
+[13058.354646]
+[13058.354655] CPU: 96 PID: 19767 Comm: fork13
+[13058.354661] Call trace:
+[13058.354667] dump_backtrace+0x0/0x310
+[13058.354672] show_stack+0x28/0x38
+[13058.354681] dump_stack+0xd8/0x108
+[13058.354687] print_address_description+0x68/0x2d0
+[13058.354690] kasan_report+0x124/0x2e0
+[13058.354697] __asan_load8+0x88/0xb0
+[13058.354702] bfq_idle_slice_timer+0xac/0x290
+[13058.354707] __hrtimer_run_queues+0x298/0x8b8
+[13058.354710] hrtimer_interrupt+0x1b8/0x678
+[13058.354716] arch_timer_handler_phys+0x4c/0x78
+[13058.354722] handle_percpu_devid_irq+0xf0/0x558
+[13058.354731] generic_handle_irq+0x50/0x70
+[13058.354735] __handle_domain_irq+0x94/0x110
+[13058.354739] gic_handle_irq+0x8c/0x1b0
+[13058.354742] el1_irq+0xb8/0x140
+[13058.354748] do_wp_page+0x260/0xe28
+[13058.354752] __handle_mm_fault+0x8ec/0x9b0
+[13058.354756] handle_mm_fault+0x280/0x460
+[13058.354762] do_page_fault+0x3ec/0x890
+[13058.354765] do_mem_abort+0xc0/0x1b0
+[13058.354768] el0_da+0x24/0x28
+[13058.354770]
+[13058.354773] Allocated by task 19731:
+[13058.354780] kasan_kmalloc+0xe0/0x190
+[13058.354784] kasan_slab_alloc+0x14/0x20
+[13058.354788] kmem_cache_alloc_node+0x130/0x440
+[13058.354793] bfq_get_queue+0x138/0x858
+[13058.354797] bfq_get_bfqq_handle_split+0xd4/0x328
+[13058.354801] bfq_init_rq+0x1f4/0x1180
+[13058.354806] bfq_insert_requests+0x264/0x1c98
+[13058.354811] blk_mq_sched_insert_requests+0x1c4/0x488
+[13058.354818] blk_mq_flush_plug_list+0x2d4/0x6e0
+[13058.354826] blk_flush_plug_list+0x230/0x548
+[13058.354830] blk_finish_plug+0x60/0x80
+[13058.354838] read_pages+0xec/0x2c0
+[13058.354842] __do_page_cache_readahead+0x374/0x438
+[13058.354846] ondemand_readahead+0x24c/0x6b0
+[13058.354851] page_cache_sync_readahead+0x17c/0x2f8
+[13058.354858] generic_file_buffered_read+0x588/0xc58
+[13058.354862] generic_file_read_iter+0x1b4/0x278
+[13058.354965] ext4_file_read_iter+0xa8/0x1d8 [ext4]
+[13058.354972] __vfs_read+0x238/0x320
+[13058.354976] vfs_read+0xbc/0x1c0
+[13058.354980] ksys_read+0xdc/0x1b8
+[13058.354984] __arm64_sys_read+0x50/0x60
+[13058.354990] el0_svc_common+0xb4/0x1d8
+[13058.354994] el0_svc_handler+0x50/0xa8
+[13058.354998] el0_svc+0x8/0xc
+[13058.354999]
+[13058.355001] Freed by task 19731:
+[13058.355007] __kasan_slab_free+0x120/0x228
+[13058.355010] kasan_slab_free+0x10/0x18
+[13058.355014] kmem_cache_free+0x288/0x3f0
+[13058.355018] bfq_put_queue+0x134/0x208
+[13058.355022] bfq_exit_icq_bfqq+0x164/0x348
+[13058.355026] bfq_exit_icq+0x28/0x40
+[13058.355030] ioc_exit_icq+0xa0/0x150
+[13058.355035] put_io_context_active+0x250/0x438
+[13058.355038] exit_io_context+0xd0/0x138
+[13058.355045] do_exit+0x734/0xc58
+[13058.355050] do_group_exit+0x78/0x220
+[13058.355054] __wake_up_parent+0x0/0x50
+[13058.355058] el0_svc_common+0xb4/0x1d8
+[13058.355062] el0_svc_handler+0x50/0xa8
+[13058.355066] el0_svc+0x8/0xc
+[13058.355067]
+[13058.355071] The buggy address belongs to the object at ffffa02cf3e63e70#012 which belongs to the cache bfq_queue of size 464
+[13058.355075] The buggy address is located 264 bytes inside of#012 464-byte region [ffffa02cf3e63e70, ffffa02cf3e64040)
+[13058.355077] The buggy address belongs to the page:
+[13058.355083] page:ffff7e80b3cf9800 count:1 mapcount:0 mapping:ffff802db5c90780 index:0xffffa02cf3e606f0 compound_mapcount: 0
+[13058.366175] flags: 0x2ffffe0000008100(slab|head)
+[13058.370781] raw: 2ffffe0000008100 ffff7e80b53b1408 ffffa02d730c1c90 ffff802db5c90780
+[13058.370787] raw: ffffa02cf3e606f0 0000000000370023 00000001ffffffff 0000000000000000
+[13058.370789] page dumped because: kasan: bad access detected
+[13058.370791]
+[13058.370792] Memory state around the buggy address:
+[13058.370797] ffffa02cf3e63e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb
+[13058.370801] ffffa02cf3e63e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+[13058.370805] >ffffa02cf3e63f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+[13058.370808] ^
+[13058.370811] ffffa02cf3e63f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+[13058.370815] ffffa02cf3e64000: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
+[13058.370817] ==================================================================
+[13058.370820] Disabling lock debugging due to kernel taint
+
+Here, we directly pass the bfqd to bfq_idle_slice_timer_body func.
+--
+V2->V3: rewrite the comment as suggested by Paolo Valente
+V1->V2: add one comment, and add Fixes and Reported-by tag.
+
+Fixes: aee69d78d ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler")
+Acked-by: Paolo Valente <paolo.valente@linaro.org>
+Reported-by: Wang Wang <wangwang2@huawei.com>
+Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
+Signed-off-by: Feilong Lin <linfeilong@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/bfq-iosched.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
+index 8c436abfaf14f..4a44c7f194353 100644
+--- a/block/bfq-iosched.c
++++ b/block/bfq-iosched.c
+@@ -6215,20 +6215,28 @@ static struct bfq_queue *bfq_init_rq(struct request *rq)
+ return bfqq;
+ }
+
+-static void bfq_idle_slice_timer_body(struct bfq_queue *bfqq)
++static void
++bfq_idle_slice_timer_body(struct bfq_data *bfqd, struct bfq_queue *bfqq)
+ {
+- struct bfq_data *bfqd = bfqq->bfqd;
+ enum bfqq_expiration reason;
+ unsigned long flags;
+
+ spin_lock_irqsave(&bfqd->lock, flags);
+- bfq_clear_bfqq_wait_request(bfqq);
+
++ /*
++ * Considering that bfqq may be in race, we should firstly check
++ * whether bfqq is in service before doing something on it. If
++ * the bfqq in race is not in service, it has already been expired
++ * through __bfq_bfqq_expire func and its wait_request flags has
++ * been cleared in __bfq_bfqd_reset_in_service func.
++ */
+ if (bfqq != bfqd->in_service_queue) {
+ spin_unlock_irqrestore(&bfqd->lock, flags);
+ return;
+ }
+
++ bfq_clear_bfqq_wait_request(bfqq);
++
+ if (bfq_bfqq_budget_timeout(bfqq))
+ /*
+ * Also here the queue can be safely expired
+@@ -6273,7 +6281,7 @@ static enum hrtimer_restart bfq_idle_slice_timer(struct hrtimer *timer)
+ * early.
+ */
+ if (bfqq)
+- bfq_idle_slice_timer_body(bfqq);
++ bfq_idle_slice_timer_body(bfqd, bfqq);
+
+ return HRTIMER_NORESTART;
+ }
+--
+2.20.1
+
--- /dev/null
+From 796b533fc5f22cd63e3c66ec64303b83a9404931 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Mar 2020 10:45:18 +0100
+Subject: block, bfq: move forward the getting of an extra ref in bfq_bfqq_move
+
+From: Paolo Valente <paolo.valente@linaro.org>
+
+[ Upstream commit fd1bb3ae54a9a2e0c42709de861c69aa146b8955 ]
+
+Commit ecedd3d7e199 ("block, bfq: get extra ref to prevent a queue
+from being freed during a group move") gets an extra reference to a
+bfq_queue before possibly deactivating it (temporarily), in
+bfq_bfqq_move(). This prevents the bfq_queue from disappearing before
+being reactivated in its new group.
+
+Yet, the bfq_queue may also be expired (i.e., its service may be
+stopped) before the bfq_queue is deactivated. And also an expiration
+may lead to a premature freeing. This commit fixes this issue by
+simply moving forward the getting of the extra reference already
+introduced by commit ecedd3d7e199 ("block, bfq: get extra ref to
+prevent a queue from being freed during a group move").
+
+Reported-by: cki-project@redhat.com
+Tested-by: cki-project@redhat.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 | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
+index f0ff6654af289..9d963ed518d1f 100644
+--- a/block/bfq-cgroup.c
++++ b/block/bfq-cgroup.c
+@@ -642,6 +642,12 @@ void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+ {
+ struct bfq_entity *entity = &bfqq->entity;
+
++ /*
++ * Get extra reference to prevent bfqq from being freed in
++ * next possible expire or deactivate.
++ */
++ bfqq->ref++;
++
+ /* If bfqq is empty, then bfq_bfqq_expire also invokes
+ * bfq_del_bfqq_busy, thereby removing bfqq and its entity
+ * from data structures related to current group. Otherwise we
+@@ -652,12 +658,6 @@ void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+ bfq_bfqq_expire(bfqd, bfqd->in_service_queue,
+ false, BFQQE_PREEMPTED);
+
+- /*
+- * get extra reference to prevent bfqq from being freed in
+- * next possible deactivate
+- */
+- bfqq->ref++;
+-
+ if (bfq_bfqq_busy(bfqq))
+ bfq_deactivate_bfqq(bfqd, bfqq, false, false);
+ else if (entity->on_st_or_in_serv)
+@@ -677,7 +677,7 @@ void bfq_bfqq_move(struct bfq_data *bfqd, struct bfq_queue *bfqq,
+
+ if (!bfqd->in_service_queue && !bfqd->rq_in_driver)
+ bfq_schedule_dispatch(bfqd);
+- /* release extra ref taken above */
++ /* release extra ref taken above, bfqq may happen to be freed now */
+ bfq_put_queue(bfqq);
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 6b2ab7b4a06a8143915a3c3b487b6a8bbdbfdd84 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Mar 2020 16:07:50 +0530
+Subject: block: Fix use-after-free issue accessing struct io_cq
+
+From: Sahitya Tummala <stummala@codeaurora.org>
+
+[ Upstream commit 30a2da7b7e225ef6c87a660419ea04d3cef3f6a7 ]
+
+There is a potential race between ioc_release_fn() and
+ioc_clear_queue() as shown below, due to which below kernel
+crash is observed. It also can result into use-after-free
+issue.
+
+context#1: context#2:
+ioc_release_fn() __ioc_clear_queue() gets the same icq
+->spin_lock(&ioc->lock); ->spin_lock(&ioc->lock);
+->ioc_destroy_icq(icq);
+ ->list_del_init(&icq->q_node);
+ ->call_rcu(&icq->__rcu_head,
+ icq_free_icq_rcu);
+->spin_unlock(&ioc->lock);
+ ->ioc_destroy_icq(icq);
+ ->hlist_del_init(&icq->ioc_node);
+ This results into below crash as this memory
+ is now used by icq->__rcu_head in context#1.
+ There is a chance that icq could be free'd
+ as well.
+
+22150.386550: <6> Unable to handle kernel write to read-only memory
+at virtual address ffffffaa8d31ca50
+...
+Call trace:
+22150.607350: <2> ioc_destroy_icq+0x44/0x110
+22150.611202: <2> ioc_clear_queue+0xac/0x148
+22150.615056: <2> blk_cleanup_queue+0x11c/0x1a0
+22150.619174: <2> __scsi_remove_device+0xdc/0x128
+22150.623465: <2> scsi_forget_host+0x2c/0x78
+22150.627315: <2> scsi_remove_host+0x7c/0x2a0
+22150.631257: <2> usb_stor_disconnect+0x74/0xc8
+22150.635371: <2> usb_unbind_interface+0xc8/0x278
+22150.639665: <2> device_release_driver_internal+0x198/0x250
+22150.644897: <2> device_release_driver+0x24/0x30
+22150.649176: <2> bus_remove_device+0xec/0x140
+22150.653204: <2> device_del+0x270/0x460
+22150.656712: <2> usb_disable_device+0x120/0x390
+22150.660918: <2> usb_disconnect+0xf4/0x2e0
+22150.664684: <2> hub_event+0xd70/0x17e8
+22150.668197: <2> process_one_work+0x210/0x480
+22150.672222: <2> worker_thread+0x32c/0x4c8
+
+Fix this by adding a new ICQ_DESTROYED flag in ioc_destroy_icq() to
+indicate this icq is once marked as destroyed. Also, ensure
+__ioc_clear_queue() is accessing icq within rcu_read_lock/unlock so
+that icq doesn't get free'd up while it is still using it.
+
+Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
+Co-developed-by: Pradeep P V K <ppvk@codeaurora.org>
+Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-ioc.c | 7 +++++++
+ include/linux/iocontext.h | 1 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/block/blk-ioc.c b/block/blk-ioc.c
+index 5ed59ac6ae58b..9df50fb507caf 100644
+--- a/block/blk-ioc.c
++++ b/block/blk-ioc.c
+@@ -84,6 +84,7 @@ static void ioc_destroy_icq(struct io_cq *icq)
+ * making it impossible to determine icq_cache. Record it in @icq.
+ */
+ icq->__rcu_icq_cache = et->icq_cache;
++ icq->flags |= ICQ_DESTROYED;
+ call_rcu(&icq->__rcu_head, icq_free_icq_rcu);
+ }
+
+@@ -212,15 +213,21 @@ static void __ioc_clear_queue(struct list_head *icq_list)
+ {
+ unsigned long flags;
+
++ rcu_read_lock();
+ while (!list_empty(icq_list)) {
+ struct io_cq *icq = list_entry(icq_list->next,
+ struct io_cq, q_node);
+ struct io_context *ioc = icq->ioc;
+
+ spin_lock_irqsave(&ioc->lock, flags);
++ if (icq->flags & ICQ_DESTROYED) {
++ spin_unlock_irqrestore(&ioc->lock, flags);
++ continue;
++ }
+ ioc_destroy_icq(icq);
+ spin_unlock_irqrestore(&ioc->lock, flags);
+ }
++ rcu_read_unlock();
+ }
+
+ /**
+diff --git a/include/linux/iocontext.h b/include/linux/iocontext.h
+index dba15ca8e60bc..1dcd9198beb7f 100644
+--- a/include/linux/iocontext.h
++++ b/include/linux/iocontext.h
+@@ -8,6 +8,7 @@
+
+ enum {
+ ICQ_EXITED = 1 << 2,
++ ICQ_DESTROYED = 1 << 3,
+ };
+
+ /*
+--
+2.20.1
+
--- /dev/null
+From ed5fb0e67620af9153b8278362d93df7fbd9bafb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Feb 2020 17:51:48 +0300
+Subject: block: keep bdi->io_pages in sync with max_sectors_kb for stacked
+ devices
+
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+
+[ Upstream commit e74d93e96d721c4297f2a900ad0191890d2fc2b0 ]
+
+Field bdi->io_pages added in commit 9491ae4aade6 ("mm: don't cap request
+size based on read-ahead setting") removes unneeded split of read requests.
+
+Stacked drivers do not call blk_queue_max_hw_sectors(). Instead they set
+limits of their devices by blk_set_stacking_limits() + disk_stack_limits().
+Field bio->io_pages stays zero until user set max_sectors_kb via sysfs.
+
+This patch updates io_pages after merging limits in disk_stack_limits().
+
+Commit c6d6e9b0f6b4 ("dm: do not allow readahead to limit IO size") fixed
+the same problem for device-mapper devices, this one fixes MD RAIDs.
+
+Fixes: 9491ae4aade6 ("mm: don't cap request size based on read-ahead setting")
+Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Reviewed-by: Bob Liu <bob.liu@oracle.com>
+Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-settings.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/block/blk-settings.c b/block/blk-settings.c
+index c8eda2e7b91e4..be1dca0103a45 100644
+--- a/block/blk-settings.c
++++ b/block/blk-settings.c
+@@ -664,6 +664,9 @@ void disk_stack_limits(struct gendisk *disk, struct block_device *bdev,
+ printk(KERN_NOTICE "%s: Warning: Device %s is misaligned\n",
+ top, bottom);
+ }
++
++ t->backing_dev_info->io_pages =
++ t->limits.max_sectors >> (PAGE_SHIFT - 9);
+ }
+ EXPORT_SYMBOL(disk_stack_limits);
+
+--
+2.20.1
+
--- /dev/null
+From 7d77bb21f7250e9ddecec7e97939f1c827365177 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Feb 2020 20:40:27 +0300
+Subject: block, zoned: fix integer overflow with BLKRESETZONE et al
+
+From: Alexey Dobriyan <adobriyan@gmail.com>
+
+[ Upstream commit 11bde986002c0af67eb92d73321d06baefae7128 ]
+
+Check for overflow in addition before checking for end-of-block-device.
+
+Steps to reproduce:
+
+ #define _GNU_SOURCE 1
+ #include <sys/ioctl.h>
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <fcntl.h>
+
+ typedef unsigned long long __u64;
+
+ struct blk_zone_range {
+ __u64 sector;
+ __u64 nr_sectors;
+ };
+
+ #define BLKRESETZONE _IOW(0x12, 131, struct blk_zone_range)
+
+ int main(void)
+ {
+ int fd = open("/dev/nullb0", O_RDWR|O_DIRECT);
+ struct blk_zone_range zr = {4096, 0xfffffffffffff000ULL};
+ ioctl(fd, BLKRESETZONE, &zr);
+ return 0;
+ }
+
+BUG: KASAN: null-ptr-deref in submit_bio_wait+0x74/0xe0
+Write of size 8 at addr 0000000000000040 by task a.out/1590
+
+CPU: 8 PID: 1590 Comm: a.out Not tainted 5.6.0-rc1-00019-g359c92c02bfa #2
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31 04/01/2014
+Call Trace:
+ dump_stack+0x76/0xa0
+ __kasan_report.cold+0x5/0x3e
+ kasan_report+0xe/0x20
+ submit_bio_wait+0x74/0xe0
+ blkdev_zone_mgmt+0x26f/0x2a0
+ blkdev_zone_mgmt_ioctl+0x14b/0x1b0
+ blkdev_ioctl+0xb28/0xe60
+ block_ioctl+0x69/0x80
+ ksys_ioctl+0x3af/0xa50
+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Alexey Dobriyan (SK hynix) <adobriyan@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-zoned.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/block/blk-zoned.c b/block/blk-zoned.c
+index 05741c6f618be..6b442ae96499a 100644
+--- a/block/blk-zoned.c
++++ b/block/blk-zoned.c
+@@ -173,7 +173,7 @@ int blkdev_zone_mgmt(struct block_device *bdev, enum req_opf op,
+ if (!op_is_zone_mgmt(op))
+ return -EOPNOTSUPP;
+
+- if (!nr_sectors || end_sector > capacity)
++ if (end_sector <= sector || end_sector > capacity)
+ /* Out of range */
+ return -EINVAL;
+
+--
+2.20.1
+
--- /dev/null
+From 325da8837409e65d1a5060415e29fac29c6ccf9b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 13:38:20 +0800
+Subject: btrfs: qgroup: ensure qgroup_rescan_running is only set when the
+ worker is at least queued
+
+From: Qu Wenruo <wqu@suse.com>
+
+[ Upstream commit d61acbbf54c612ea9bf67eed609494cda0857b3a ]
+
+[BUG]
+There are some reports about btrfs wait forever to unmount itself, with
+the following call trace:
+
+ INFO: task umount:4631 blocked for more than 491 seconds.
+ Tainted: G X 5.3.8-2-default #1
+ "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+ umount D 0 4631 3337 0x00000000
+ Call Trace:
+ ([<00000000174adf7a>] __schedule+0x342/0x748)
+ [<00000000174ae3ca>] schedule+0x4a/0xd8
+ [<00000000174b1f08>] schedule_timeout+0x218/0x420
+ [<00000000174af10c>] wait_for_common+0x104/0x1d8
+ [<000003ff804d6994>] btrfs_qgroup_wait_for_completion+0x84/0xb0 [btrfs]
+ [<000003ff8044a616>] close_ctree+0x4e/0x380 [btrfs]
+ [<0000000016fa3136>] generic_shutdown_super+0x8e/0x158
+ [<0000000016fa34d6>] kill_anon_super+0x26/0x40
+ [<000003ff8041ba88>] btrfs_kill_super+0x28/0xc8 [btrfs]
+ [<0000000016fa39f8>] deactivate_locked_super+0x68/0x98
+ [<0000000016fcb198>] cleanup_mnt+0xc0/0x140
+ [<0000000016d6a846>] task_work_run+0xc6/0x110
+ [<0000000016d04f76>] do_notify_resume+0xae/0xb8
+ [<00000000174b30ae>] system_call+0xe2/0x2c8
+
+[CAUSE]
+The problem happens when we have called qgroup_rescan_init(), but
+not queued the worker. It can be caused mostly by error handling.
+
+ Qgroup ioctl thread | Unmount thread
+----------------------------------------+-----------------------------------
+ |
+btrfs_qgroup_rescan() |
+|- qgroup_rescan_init() |
+| |- qgroup_rescan_running = true; |
+| |
+|- trans = btrfs_join_transaction() |
+| Some error happened |
+| |
+|- btrfs_qgroup_rescan() returns error |
+ But qgroup_rescan_running == true; |
+ | close_ctree()
+ | |- btrfs_qgroup_wait_for_completion()
+ | |- running == true;
+ | |- wait_for_completion();
+
+btrfs_qgroup_rescan_worker is never queued, thus no one is going to wake
+up close_ctree() and we get a deadlock.
+
+All involved qgroup_rescan_init() callers are:
+
+- btrfs_qgroup_rescan()
+ The example above. It's possible to trigger the deadlock when error
+ happened.
+
+- btrfs_quota_enable()
+ Not possible. Just after qgroup_rescan_init() we queue the work.
+
+- btrfs_read_qgroup_config()
+ It's possible to trigger the deadlock. It only init the work, the
+ work queueing happens in btrfs_qgroup_rescan_resume().
+ Thus if error happened in between, deadlock is possible.
+
+We shouldn't set fs_info->qgroup_rescan_running just in
+qgroup_rescan_init(), as at that stage we haven't yet queued qgroup
+rescan worker to run.
+
+[FIX]
+Set qgroup_rescan_running before queueing the work, so that we ensure
+the rescan work is queued when we wait for it.
+
+Fixes: 8d9eddad1946 ("Btrfs: fix qgroup rescan worker initialization")
+Signed-off-by: Jeff Mahoney <jeffm@suse.com>
+[ Change subject and cause analyse, use a smaller fix ]
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/qgroup.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
+index ff1870ff3474a..afc9752e984c3 100644
+--- a/fs/btrfs/qgroup.c
++++ b/fs/btrfs/qgroup.c
+@@ -1030,6 +1030,7 @@ out_add_root:
+ ret = qgroup_rescan_init(fs_info, 0, 1);
+ if (!ret) {
+ qgroup_rescan_zero_tracking(fs_info);
++ fs_info->qgroup_rescan_running = true;
+ btrfs_queue_work(fs_info->qgroup_rescan_workers,
+ &fs_info->qgroup_rescan_work);
+ }
+@@ -3263,7 +3264,6 @@ qgroup_rescan_init(struct btrfs_fs_info *fs_info, u64 progress_objectid,
+ sizeof(fs_info->qgroup_rescan_progress));
+ fs_info->qgroup_rescan_progress.objectid = progress_objectid;
+ init_completion(&fs_info->qgroup_rescan_completion);
+- fs_info->qgroup_rescan_running = true;
+
+ spin_unlock(&fs_info->qgroup_lock);
+ mutex_unlock(&fs_info->qgroup_rescan_lock);
+@@ -3326,8 +3326,11 @@ btrfs_qgroup_rescan(struct btrfs_fs_info *fs_info)
+
+ qgroup_rescan_zero_tracking(fs_info);
+
++ mutex_lock(&fs_info->qgroup_rescan_lock);
++ fs_info->qgroup_rescan_running = true;
+ btrfs_queue_work(fs_info->qgroup_rescan_workers,
+ &fs_info->qgroup_rescan_work);
++ mutex_unlock(&fs_info->qgroup_rescan_lock);
+
+ return 0;
+ }
+@@ -3363,9 +3366,13 @@ int btrfs_qgroup_wait_for_completion(struct btrfs_fs_info *fs_info,
+ void
+ btrfs_qgroup_rescan_resume(struct btrfs_fs_info *fs_info)
+ {
+- if (fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN)
++ if (fs_info->qgroup_flags & BTRFS_QGROUP_STATUS_FLAG_RESCAN) {
++ mutex_lock(&fs_info->qgroup_rescan_lock);
++ fs_info->qgroup_rescan_running = true;
+ btrfs_queue_work(fs_info->qgroup_rescan_workers,
+ &fs_info->qgroup_rescan_work);
++ mutex_unlock(&fs_info->qgroup_rescan_lock);
++ }
+ }
+
+ /*
+--
+2.20.1
+
--- /dev/null
+From 1c53ef2c25cb98622e2b986e9ae9a613e3e902ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 11:18:30 -0500
+Subject: btrfs: remove a BUG_ON() from merge_reloc_roots()
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit 7b7b74315b24dc064bc1c683659061c3d48f8668 ]
+
+This was pretty subtle, we default to reloc roots having 0 root refs, so
+if we crash in the middle of the relocation they can just be deleted.
+If we successfully complete the relocation operations we'll set our root
+refs to 1 in prepare_to_merge() and then go on to merge_reloc_roots().
+
+At prepare_to_merge() time if any of the reloc roots have a 0 reference
+still, we will remove that reloc root from our reloc root rb tree, and
+then clean it up later.
+
+However this only happens if we successfully start a transaction. If
+we've aborted previously we will skip this step completely, and only
+have reloc roots with a reference count of 0, but were never properly
+removed from the reloc control's rb tree.
+
+This isn't a problem per-se, our references are held by the list the
+reloc roots are on, and by the original root the reloc root belongs to.
+If we end up in this situation all the reloc roots will be added to the
+dirty_reloc_list, and then properly dropped at that point. The reloc
+control will be free'd and the rb tree is no longer used.
+
+There were two options when fixing this, one was to remove the BUG_ON(),
+the other was to make prepare_to_merge() handle the case where we
+couldn't start a trans handle.
+
+IMO this is the cleaner solution. I started with handling the error in
+prepare_to_merge(), but it turned out super ugly. And in the end this
+BUG_ON() simply doesn't matter, the cleanup was happening properly, we
+were just panicing because this BUG_ON() only matters in the success
+case. So I've opted to just remove it and add a comment where it was.
+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/relocation.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
+index 995d4b8b1cfd9..db6abe3f10e57 100644
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -2561,7 +2561,21 @@ out:
+ free_reloc_roots(&reloc_roots);
+ }
+
+- BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
++ /*
++ * We used to have
++ *
++ * BUG_ON(!RB_EMPTY_ROOT(&rc->reloc_root_tree.rb_root));
++ *
++ * here, but it's wrong. If we fail to start the transaction in
++ * prepare_to_merge() we will have only 0 ref reloc roots, none of which
++ * have actually been removed from the reloc_root_tree rb tree. This is
++ * fine because we're bailing here, and we hold a reference on the root
++ * for the list that holds it, so these roots will be cleaned up when we
++ * do the reloc_dirty_list afterwards. Meanwhile the root->reloc_root
++ * will be cleaned up on unmount.
++ *
++ * The remaining nodes will be cleaned up by free_reloc_control.
++ */
+ }
+
+ static void free_block_list(struct rb_root *blocks)
+--
+2.20.1
+
--- /dev/null
+From 46295bfa4e9c1e4f38f986b6ba933116cfae06a7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Mar 2020 17:17:07 -0400
+Subject: btrfs: restart relocate_tree_blocks properly
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit 50dbbb71c79df89532ec41d118d59386e5a877e3 ]
+
+There are two bugs here, but fixing them independently would just result
+in pain if you happened to bisect between the two patches.
+
+First is how we handle the -EAGAIN from relocate_tree_block(). We don't
+set error, unless we happen to be the first node, which makes no sense,
+I have no idea what the code was trying to accomplish here.
+
+We in fact _do_ want err set here so that we know we need to restart in
+relocate_block_group(). Also we need finish_pending_nodes() to not
+actually call link_to_upper(), because we didn't actually relocate the
+block.
+
+And then if we do get -EAGAIN we do not want to set our backref cache
+last_trans to the one before ours. This would force us to update our
+backref cache if we didn't cross transaction ids, which would mean we'd
+have some nodes updated to their new_bytenr, but still able to find
+their old bytenr because we're searching the same commit root as the
+last time we went through relocate_tree_blocks.
+
+Fixing these two things keeps us from panicing when we start breaking
+out of relocate_tree_blocks() either for delayed ref flushing or enospc.
+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/relocation.c | 11 ++---------
+ 1 file changed, 2 insertions(+), 9 deletions(-)
+
+diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
+index db6abe3f10e57..d7e8839048d71 100644
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -3175,9 +3175,8 @@ int relocate_tree_blocks(struct btrfs_trans_handle *trans,
+ ret = relocate_tree_block(trans, rc, node, &block->key,
+ path);
+ if (ret < 0) {
+- if (ret != -EAGAIN || &block->rb_node == rb_first(blocks))
+- err = ret;
+- goto out;
++ err = ret;
++ break;
+ }
+ }
+ out:
+@@ -4151,12 +4150,6 @@ restart:
+ if (!RB_EMPTY_ROOT(&blocks)) {
+ ret = relocate_tree_blocks(trans, rc, &blocks);
+ if (ret < 0) {
+- /*
+- * if we fail to relocate tree blocks, force to update
+- * backref cache when committing transaction.
+- */
+- rc->backref_cache.last_trans = trans->transid - 1;
+-
+ if (ret != -EAGAIN) {
+ err = ret;
+ break;
+--
+2.20.1
+
--- /dev/null
+From 7fd16ab66e93d4a9013c34efebedc30d3054564f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 13 Mar 2020 17:17:08 -0400
+Subject: btrfs: track reloc roots based on their commit root bytenr
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit ea287ab157c2816bf12aad4cece41372f9d146b4 ]
+
+We always search the commit root of the extent tree for looking up back
+references, however we track the reloc roots based on their current
+bytenr.
+
+This is wrong, if we commit the transaction between relocating tree
+blocks we could end up in this code in build_backref_tree
+
+ if (key.objectid == key.offset) {
+ /*
+ * Only root blocks of reloc trees use backref
+ * pointing to itself.
+ */
+ root = find_reloc_root(rc, cur->bytenr);
+ ASSERT(root);
+ cur->root = root;
+ break;
+ }
+
+find_reloc_root() is looking based on the bytenr we had in the commit
+root, but if we've COWed this reloc root we will not find that bytenr,
+and we will trip over the ASSERT(root).
+
+Fix this by using the commit_root->start bytenr for indexing the commit
+root. Then we change the __update_reloc_root() caller to be used when
+we switch the commit root for the reloc root during commit.
+
+This fixes the panic I was seeing when we started throttling relocation
+for delayed refs.
+
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/relocation.c | 17 +++++++----------
+ 1 file changed, 7 insertions(+), 10 deletions(-)
+
+diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
+index d7e8839048d71..8e86934a17c35 100644
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -1298,7 +1298,7 @@ static int __must_check __add_reloc_root(struct btrfs_root *root)
+ if (!node)
+ return -ENOMEM;
+
+- node->bytenr = root->node->start;
++ node->bytenr = root->commit_root->start;
+ node->data = root;
+
+ spin_lock(&rc->reloc_root_tree.lock);
+@@ -1329,10 +1329,11 @@ static void __del_reloc_root(struct btrfs_root *root)
+ if (rc && root->node) {
+ spin_lock(&rc->reloc_root_tree.lock);
+ rb_node = tree_search(&rc->reloc_root_tree.rb_root,
+- root->node->start);
++ root->commit_root->start);
+ if (rb_node) {
+ node = rb_entry(rb_node, struct mapping_node, rb_node);
+ rb_erase(&node->rb_node, &rc->reloc_root_tree.rb_root);
++ RB_CLEAR_NODE(&node->rb_node);
+ }
+ spin_unlock(&rc->reloc_root_tree.lock);
+ if (!node)
+@@ -1350,7 +1351,7 @@ static void __del_reloc_root(struct btrfs_root *root)
+ * helper to update the 'address of tree root -> reloc tree'
+ * mapping
+ */
+-static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
++static int __update_reloc_root(struct btrfs_root *root)
+ {
+ struct btrfs_fs_info *fs_info = root->fs_info;
+ struct rb_node *rb_node;
+@@ -1359,7 +1360,7 @@ static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
+
+ spin_lock(&rc->reloc_root_tree.lock);
+ rb_node = tree_search(&rc->reloc_root_tree.rb_root,
+- root->node->start);
++ root->commit_root->start);
+ if (rb_node) {
+ node = rb_entry(rb_node, struct mapping_node, rb_node);
+ rb_erase(&node->rb_node, &rc->reloc_root_tree.rb_root);
+@@ -1371,7 +1372,7 @@ static int __update_reloc_root(struct btrfs_root *root, u64 new_bytenr)
+ BUG_ON((struct btrfs_root *)node->data != root);
+
+ spin_lock(&rc->reloc_root_tree.lock);
+- node->bytenr = new_bytenr;
++ node->bytenr = root->node->start;
+ rb_node = tree_insert(&rc->reloc_root_tree.rb_root,
+ node->bytenr, &node->rb_node);
+ spin_unlock(&rc->reloc_root_tree.lock);
+@@ -1529,6 +1530,7 @@ int btrfs_update_reloc_root(struct btrfs_trans_handle *trans,
+ }
+
+ if (reloc_root->commit_root != reloc_root->node) {
++ __update_reloc_root(reloc_root);
+ btrfs_set_root_node(root_item, reloc_root->node);
+ free_extent_buffer(reloc_root->commit_root);
+ reloc_root->commit_root = btrfs_root_node(reloc_root);
+@@ -4727,11 +4729,6 @@ int btrfs_reloc_cow_block(struct btrfs_trans_handle *trans,
+ BUG_ON(rc->stage == UPDATE_DATA_PTRS &&
+ root->root_key.objectid == BTRFS_DATA_RELOC_TREE_OBJECTID);
+
+- if (root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) {
+- if (buf == root->node)
+- __update_reloc_root(root, cow->start);
+- }
+-
+ level = btrfs_header_level(buf);
+ if (btrfs_header_generation(buf) <=
+ btrfs_root_last_snapshot(&root->root_item))
+--
+2.20.1
+
--- /dev/null
+From a7e9dde1e6787a5395e760fbbdf2acc235eb5786 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 16 Mar 2020 11:52:56 +0200
+Subject: clocksource/drivers/timer-microchip-pit64b: Fix rate for gck
+
+From: Claudiu Beznea <claudiu.beznea@microchip.com>
+
+[ Upstream commit 0585244523f0f4de7e4480375e871617a79cab98 ]
+
+Generic clock rate needs to be set in case it was selected as timer clock
+source in mchp_pit64b_init_mode(). Otherwise it will be enabled with wrong
+rate.
+
+Fixes: 625022a5f160 ("clocksource/drivers/timer-microchip-pit64b: Add Microchip PIT64B support")
+Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/1584352376-32585-1-git-send-email-claudiu.beznea@microchip.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clocksource/timer-microchip-pit64b.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/clocksource/timer-microchip-pit64b.c b/drivers/clocksource/timer-microchip-pit64b.c
+index bd63d3484838a..59e11ca8ee73e 100644
+--- a/drivers/clocksource/timer-microchip-pit64b.c
++++ b/drivers/clocksource/timer-microchip-pit64b.c
+@@ -264,6 +264,7 @@ static int __init mchp_pit64b_init_mode(struct mchp_pit64b_timer *timer,
+
+ if (!best_diff) {
+ timer->mode |= MCHP_PIT64B_MR_SGCLK;
++ clk_set_rate(timer->gclk, gclk_round);
+ goto done;
+ }
+
+--
+2.20.1
+
--- /dev/null
+From cee610ea32e071aa0b5dd67aa7a60be49748f45f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 10:14:49 +0800
+Subject: cpufreq: imx6q: fix error handling
+
+From: Peng Fan <peng.fan@nxp.com>
+
+[ Upstream commit 3646f50a3838c5949a89ecbdb868497cdc05b8fd ]
+
+When speed checking failed, direclty jumping to put_node label
+is not correct. Need jump to out_free_opp to avoid resources leak.
+
+Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
+Signed-off-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/imx6q-cpufreq.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
+index 1fcbbd53a48a2..edef3399c9794 100644
+--- a/drivers/cpufreq/imx6q-cpufreq.c
++++ b/drivers/cpufreq/imx6q-cpufreq.c
+@@ -381,23 +381,24 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
+ goto put_reg;
+ }
+
++ /* Because we have added the OPPs here, we must free them */
++ free_opp = true;
++
+ if (of_machine_is_compatible("fsl,imx6ul") ||
+ of_machine_is_compatible("fsl,imx6ull")) {
+ ret = imx6ul_opp_check_speed_grading(cpu_dev);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+- goto put_node;
++ goto out_free_opp;
+
+ dev_err(cpu_dev, "failed to read ocotp: %d\n",
+ ret);
+- goto put_node;
++ goto out_free_opp;
+ }
+ } else {
+ imx6q_opp_check_speed_grading(cpu_dev);
+ }
+
+- /* Because we have added the OPPs here, we must free them */
+- free_opp = true;
+ num = dev_pm_opp_get_opp_count(cpu_dev);
+ if (num < 0) {
+ ret = num;
+--
+2.20.1
+
--- /dev/null
+From 5dae441631f4c7640d165bb4517c734e1ac90941 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Feb 2020 12:58:07 +0100
+Subject: cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL
+
+From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+
+[ Upstream commit 36eb7dc1bd42fe5f850329c893768ff89b696fba ]
+
+imx6ul_opp_check_speed_grading is called for both i.MX6UL and i.MX6ULL.
+Since the i.MX6ULL was introduced to a separate ocotp compatible node
+later, it is possible that the i.MX6ULL has also dtbs with
+"fsl,imx6ull-ocotp". On a system without nvmem-cell speed grade a
+missing check on this node causes a driver fail without considering
+the cpu speed grade.
+
+This patch prevents unwanted cpu overclocking on i.MX6ULL with compatible
+node "fsl,imx6ull-ocotp" in old dtbs without nvmem-cell speed grade.
+
+Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
+Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/cpufreq/imx6q-cpufreq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
+index 648a09a1778a3..1fcbbd53a48a2 100644
+--- a/drivers/cpufreq/imx6q-cpufreq.c
++++ b/drivers/cpufreq/imx6q-cpufreq.c
+@@ -280,6 +280,9 @@ static int imx6ul_opp_check_speed_grading(struct device *dev)
+ void __iomem *base;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-ocotp");
++ if (!np)
++ np = of_find_compatible_node(NULL, NULL,
++ "fsl,imx6ull-ocotp");
+ if (!np)
+ return -ENOENT;
+
+--
+2.20.1
+
--- /dev/null
+From 06a2eac9146b81252a825eeaa061f470584616fe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Feb 2020 04:31:50 +0000
+Subject: debugfs: Check module state before warning in
+ {full/open}_proxy_open()
+
+From: Taehee Yoo <ap420073@gmail.com>
+
+[ Upstream commit 275678e7a9be6a0ea9c1bb493e48abf2f4a01be5 ]
+
+When the module is being removed, the module state is set to
+MODULE_STATE_GOING. At this point, try_module_get() fails.
+And when {full/open}_proxy_open() is being called,
+it calls try_module_get() to try to hold module reference count.
+If it fails, it warns about the possibility of debugfs file leak.
+
+If {full/open}_proxy_open() is called while the module is being removed,
+it fails to hold the module.
+So, It warns about debugfs file leak. But it is not the debugfs file
+leak case. So, this patch just adds module state checking routine
+in the {full/open}_proxy_open().
+
+Test commands:
+ #SHELL1
+ while :
+ do
+ modprobe netdevsim
+ echo 1 > /sys/bus/netdevsim/new_device
+ modprobe -rv netdevsim
+ done
+
+ #SHELL2
+ while :
+ do
+ cat /sys/kernel/debug/netdevsim/netdevsim1/ports/0/ipsec
+ done
+
+Splat looks like:
+[ 298.766738][T14664] debugfs file owner did not clean up at exit: ipsec
+[ 298.766766][T14664] WARNING: CPU: 2 PID: 14664 at fs/debugfs/file.c:312 full_proxy_open+0x10f/0x650
+[ 298.768595][T14664] Modules linked in: netdevsim(-) openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 n][ 298.771343][T14664] CPU: 2 PID: 14664 Comm: cat Tainted: G W 5.5.0+ #1
+[ 298.772373][T14664] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
+[ 298.773545][T14664] RIP: 0010:full_proxy_open+0x10f/0x650
+[ 298.774247][T14664] Code: 48 c1 ea 03 80 3c 02 00 0f 85 c1 04 00 00 49 8b 3c 24 e8 e4 b5 78 ff 84 c0 75 2d 4c 89 ee 48
+[ 298.776782][T14664] RSP: 0018:ffff88805b7df9b8 EFLAGS: 00010282[ 298.777583][T14664] RAX: dffffc0000000008 RBX: ffff8880511725c0 RCX: 0000000000000000
+[ 298.778610][T14664] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8880540c5c14
+[ 298.779637][T14664] RBP: 0000000000000000 R08: fffffbfff15235ad R09: 0000000000000000
+[ 298.780664][T14664] R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffc06b5000
+[ 298.781702][T14664] R13: ffff88804c234a88 R14: ffff88804c22dd00 R15: ffffffff8a1b5660
+[ 298.782722][T14664] FS: 00007fafa13a8540(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
+[ 298.783845][T14664] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 298.784672][T14664] CR2: 00007fafa0e9cd10 CR3: 000000004b286005 CR4: 00000000000606e0
+[ 298.785739][T14664] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 298.786769][T14664] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 298.787785][T14664] Call Trace:
+[ 298.788237][T14664] do_dentry_open+0x63c/0xf50
+[ 298.788872][T14664] ? open_proxy_open+0x270/0x270
+[ 298.789524][T14664] ? __x64_sys_fchdir+0x180/0x180
+[ 298.790169][T14664] ? inode_permission+0x65/0x390
+[ 298.790832][T14664] path_openat+0xc45/0x2680
+[ 298.791425][T14664] ? save_stack+0x69/0x80
+[ 298.791988][T14664] ? save_stack+0x19/0x80
+[ 298.792544][T14664] ? path_mountpoint+0x2e0/0x2e0
+[ 298.793233][T14664] ? check_chain_key+0x236/0x5d0
+[ 298.793910][T14664] ? sched_clock_cpu+0x18/0x170
+[ 298.794527][T14664] ? find_held_lock+0x39/0x1d0
+[ 298.795153][T14664] do_filp_open+0x16a/0x260
+[ ... ]
+
+Fixes: 9fd4dcece43a ("debugfs: prevent access to possibly dead file_operations at file open")
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Link: https://lore.kernel.org/r/20200218043150.29447-1-ap420073@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/debugfs/file.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
+index db987b5110a99..f34757e8f25f8 100644
+--- a/fs/debugfs/file.c
++++ b/fs/debugfs/file.c
+@@ -175,8 +175,13 @@ static int open_proxy_open(struct inode *inode, struct file *filp)
+ if (r)
+ goto out;
+
+- real_fops = fops_get(real_fops);
+- if (!real_fops) {
++ if (!fops_get(real_fops)) {
++#ifdef MODULE
++ if (real_fops->owner &&
++ real_fops->owner->state == MODULE_STATE_GOING)
++ goto out;
++#endif
++
+ /* Huh? Module did not clean up after itself at exit? */
+ WARN(1, "debugfs file owner did not clean up at exit: %pd",
+ dentry);
+@@ -305,8 +310,13 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
+ if (r)
+ goto out;
+
+- real_fops = fops_get(real_fops);
+- if (!real_fops) {
++ if (!fops_get(real_fops)) {
++#ifdef MODULE
++ if (real_fops->owner &&
++ real_fops->owner->state == MODULE_STATE_GOING)
++ goto out;
++#endif
++
+ /* Huh? Module did not cleanup after itself at exit? */
+ WARN(1, "debugfs file owner did not clean up at exit: %pd",
+ dentry);
+--
+2.20.1
+
--- /dev/null
+From ad551c17bea612e033ab756567924963695c56f5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 12:45:27 +0100
+Subject: dma-mapping: Fix dma_pgprot() for unencrypted coherent pages
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+[ Upstream commit 17c4a2ae15a7aaefe84bdb271952678c5c9cd8e1 ]
+
+When dma_mmap_coherent() sets up a mapping to unencrypted coherent memory
+under SEV encryption and sometimes under SME encryption, it will actually
+set up an encrypted mapping rather than an unencrypted, causing devices
+that DMAs from that memory to read encrypted contents. Fix this.
+
+When force_dma_unencrypted() returns true, the linear kernel map of the
+coherent pages have had the encryption bit explicitly cleared and the
+page content is unencrypted. Make sure that any additional PTEs we set
+up to these pages also have the encryption bit cleared by having
+dma_pgprot() return a protection with the encryption bit cleared in this
+case.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Link: https://lkml.kernel.org/r/20200304114527.3636-3-thomas_os@shipmail.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/dma/mapping.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
+index 12ff766ec1fa3..98e3d873792ea 100644
+--- a/kernel/dma/mapping.c
++++ b/kernel/dma/mapping.c
+@@ -154,6 +154,8 @@ EXPORT_SYMBOL(dma_get_sgtable_attrs);
+ */
+ pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
+ {
++ if (force_dma_unencrypted(dev))
++ prot = pgprot_decrypted(prot);
+ if (dev_is_dma_coherent(dev) ||
+ (IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
+ (attrs & DMA_ATTR_NON_CONSISTENT)))
+--
+2.20.1
+
--- /dev/null
+From d16835acfd3dba8dea4fc96dbee8b8cfb785e949 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 23 Jan 2020 09:03:00 +0000
+Subject: EDAC/mc: Report "unknown memory" on too many DIMM labels found
+
+From: Robert Richter <rrichter@marvell.com>
+
+[ Upstream commit 65bb4d1af92cf007adc0a0c59dadcc393c5cada6 ]
+
+There is a limitation to report only EDAC_MAX_LABELS in e->label of
+the error descriptor. This is to prevent a potential string overflow.
+
+The current implementation falls back to "any memory" in this case and
+also stops all further processing to find a unique row and channel of
+the possible error location.
+
+Reporting "any memory" is wrong as the memory controller reported an
+error location for one of the layers. Instead, report "unknown memory"
+and also do not break early in the loop to further check row and channel
+for uniqueness.
+
+ [ bp: Massage commit message. ]
+
+Signed-off-by: Robert Richter <rrichter@marvell.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Aristeu Rozanski <aris@redhat.com>
+Link: https://lkml.kernel.org/r/20200123090210.26933-7-rrichter@marvell.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/edac/edac_mc.c | 21 +++++++++++----------
+ 1 file changed, 11 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
+index 69e0d90460e6c..2349f2ad946bb 100644
+--- a/drivers/edac/edac_mc.c
++++ b/drivers/edac/edac_mc.c
+@@ -1180,20 +1180,21 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
+ * channel/memory controller/... may be affected.
+ * Also, don't show errors for empty DIMM slots.
+ */
+- if (!e->enable_per_layer_report || !dimm->nr_pages)
++ if (!dimm->nr_pages)
+ continue;
+
+- if (n_labels >= EDAC_MAX_LABELS) {
+- e->enable_per_layer_report = false;
+- break;
+- }
+ n_labels++;
+- if (p != e->label) {
+- strcpy(p, OTHER_LABEL);
+- p += strlen(OTHER_LABEL);
++ if (n_labels > EDAC_MAX_LABELS) {
++ p = e->label;
++ *p = '\0';
++ } else {
++ if (p != e->label) {
++ strcpy(p, OTHER_LABEL);
++ p += strlen(OTHER_LABEL);
++ }
++ strcpy(p, dimm->label);
++ p += strlen(p);
+ }
+- strcpy(p, dimm->label);
+- p += strlen(p);
+
+ /*
+ * get csrow/channel of the DIMM, in order to allow
+--
+2.20.1
+
--- /dev/null
+From 571a68a7efc42b74003025b9e3e849ffb69e8334 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 8 Mar 2020 09:08:51 +0100
+Subject: efi/x86: Ignore the memory attributes table on i386
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+[ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ]
+
+Commit:
+
+ 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures")
+
+moved the call to efi_memattr_init() from ARM specific to the generic
+EFI init code, in order to be able to apply the restricted permissions
+described in that table on x86 as well.
+
+We never enabled this feature fully on i386, and so mapping and
+reserving this table is pointless. However, due to the early call to
+memblock_reserve(), the memory bookkeeping gets confused to the point
+where it produces the splat below when we try to map the memory later
+on:
+
+ ------------[ cut here ]------------
+ ioremap on RAM at 0x3f251000 - 0x3fa1afff
+ WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ...
+ Modules linked in:
+ CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
+ EIP: __ioremap_caller.constprop.0+0x249/0x260
+ Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ...
+ EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001
+ ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0
+ DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296
+ CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690
+ Call Trace:
+ ioremap_cache+0xd/0x10
+ ? old_map_region+0x72/0x9d
+ old_map_region+0x72/0x9d
+ efi_map_region+0x8/0xa
+ efi_enter_virtual_mode+0x260/0x43b
+ start_kernel+0x329/0x3aa
+ i386_start_kernel+0xa7/0xab
+ startup_32_smp+0x164/0x168
+ ---[ end trace e15ccf6b9f356833 ]---
+
+Let's work around this by disregarding the memory attributes table
+altogether on i386, which does not result in a loss of functionality
+or protection, given that we never consumed the contents.
+
+Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ")
+Tested-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org
+Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/efi/efi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
+index 21ea99f651134..77cb95f70ed66 100644
+--- a/drivers/firmware/efi/efi.c
++++ b/drivers/firmware/efi/efi.c
+@@ -570,7 +570,7 @@ int __init efi_config_parse_tables(void *config_tables, int count, int sz,
+ }
+ }
+
+- if (efi_enabled(EFI_MEMMAP))
++ if (!IS_ENABLED(CONFIG_X86_32) && efi_enabled(EFI_MEMMAP))
+ efi_memattr_init();
+
+ efi_tpm_eventlog_init();
+--
+2.20.1
+
--- /dev/null
+From 39ee6b9e57ae564023940255f60a1cc36f0bdb21 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 16:35:06 +0000
+Subject: firmware: arm_sdei: fix double-lock on hibernate with shared events
+
+From: James Morse <james.morse@arm.com>
+
+[ Upstream commit 6ded0b61cf638bf9f8efe60ab8ba23db60ea9763 ]
+
+SDEI has private events that must be registered on each CPU. When
+CPUs come and go they must re-register and re-enable their private
+events. Each event has flags to indicate whether this should happen
+to protect against an event being registered on a CPU coming online,
+while all the others are unregistering the event.
+
+These flags are protected by the sdei_list_lock spinlock, because
+the cpuhp callbacks can't take the mutex.
+
+Hibernate needs to unregister all events, but keep the in-memory
+re-register and re-enable as they are. sdei_unregister_shared()
+takes the spinlock to walk the list, then calls _sdei_event_unregister()
+on each shared event. _sdei_event_unregister() tries to take the
+same spinlock to update re-register and re-enable. This doesn't go
+so well.
+
+Push the re-register and re-enable updates out to their callers.
+sdei_unregister_shared() doesn't want these values updated, so
+doesn't need to do anything.
+
+This also fixes shared events getting lost over hibernate as this
+path made them look unregistered.
+
+Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states")
+Reported-by: Liguang Zhang <zhangliguang@linux.alibaba.com>
+Signed-off-by: James Morse <james.morse@arm.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/arm_sdei.c | 32 +++++++++++++++-----------------
+ 1 file changed, 15 insertions(+), 17 deletions(-)
+
+diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
+index a479023fa036e..77eaa9a2fd156 100644
+--- a/drivers/firmware/arm_sdei.c
++++ b/drivers/firmware/arm_sdei.c
+@@ -491,11 +491,6 @@ static int _sdei_event_unregister(struct sdei_event *event)
+ {
+ lockdep_assert_held(&sdei_events_lock);
+
+- spin_lock(&sdei_list_lock);
+- event->reregister = false;
+- event->reenable = false;
+- spin_unlock(&sdei_list_lock);
+-
+ if (event->type == SDEI_EVENT_TYPE_SHARED)
+ return sdei_api_event_unregister(event->event_num);
+
+@@ -518,6 +513,11 @@ int sdei_event_unregister(u32 event_num)
+ break;
+ }
+
++ spin_lock(&sdei_list_lock);
++ event->reregister = false;
++ event->reenable = false;
++ spin_unlock(&sdei_list_lock);
++
+ err = _sdei_event_unregister(event);
+ if (err)
+ break;
+@@ -585,26 +585,15 @@ static int _sdei_event_register(struct sdei_event *event)
+
+ lockdep_assert_held(&sdei_events_lock);
+
+- spin_lock(&sdei_list_lock);
+- event->reregister = true;
+- spin_unlock(&sdei_list_lock);
+-
+ if (event->type == SDEI_EVENT_TYPE_SHARED)
+ return sdei_api_event_register(event->event_num,
+ sdei_entry_point,
+ event->registered,
+ SDEI_EVENT_REGISTER_RM_ANY, 0);
+
+-
+ err = sdei_do_cross_call(_local_event_register, event);
+- if (err) {
+- spin_lock(&sdei_list_lock);
+- event->reregister = false;
+- event->reenable = false;
+- spin_unlock(&sdei_list_lock);
+-
++ if (err)
+ sdei_do_cross_call(_local_event_unregister, event);
+- }
+
+ return err;
+ }
+@@ -632,8 +621,17 @@ int sdei_event_register(u32 event_num, sdei_event_callback *cb, void *arg)
+ break;
+ }
+
++ spin_lock(&sdei_list_lock);
++ event->reregister = true;
++ spin_unlock(&sdei_list_lock);
++
+ err = _sdei_event_register(event);
+ if (err) {
++ spin_lock(&sdei_list_lock);
++ event->reregister = false;
++ event->reenable = false;
++ spin_unlock(&sdei_list_lock);
++
+ sdei_event_destroy(event);
+ pr_warn("Failed to register event %u: %d\n", event_num,
+ err);
+--
+2.20.1
+
--- /dev/null
+From ce4a1aa176dcd01db93bf8abc31f2413096d5b34 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 10:36:08 +0800
+Subject: firmware: fix a double abort case with fw_load_sysfs_fallback
+
+From: Junyong Sun <sunjy516@gmail.com>
+
+[ Upstream commit bcfbd3523f3c6eea51a74d217a8ebc5463bcb7f4 ]
+
+fw_sysfs_wait_timeout may return err with -ENOENT
+at fw_load_sysfs_fallback and firmware is already
+in abort status, no need to abort again, so skip it.
+
+This issue is caused by concurrent situation like below:
+when thread 1# wait firmware loading, thread 2# may write
+-1 to abort loading and wakeup thread 1# before it timeout.
+so wait_for_completion_killable_timeout of thread 1# would
+return remaining time which is != 0 with fw_st->status
+FW_STATUS_ABORTED.And the results would be converted into
+err -ENOENT in __fw_state_wait_common and transfered to
+fw_load_sysfs_fallback in thread 1#.
+The -ENOENT means firmware status is already at ABORTED,
+so fw_load_sysfs_fallback no need to get mutex to abort again.
+-----------------------------
+thread 1#,wait for loading
+fw_load_sysfs_fallback
+ ->fw_sysfs_wait_timeout
+ ->__fw_state_wait_common
+ ->wait_for_completion_killable_timeout
+
+in __fw_state_wait_common,
+...
+93 ret = wait_for_completion_killable_timeout(&fw_st->completion, timeout);
+94 if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
+95 return -ENOENT;
+96 if (!ret)
+97 return -ETIMEDOUT;
+98
+99 return ret < 0 ? ret : 0;
+-----------------------------
+thread 2#, write -1 to abort loading
+firmware_loading_store
+ ->fw_load_abort
+ ->__fw_load_abort
+ ->fw_state_aborted
+ ->__fw_state_set
+ ->complete_all
+
+in __fw_state_set,
+...
+111 if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED)
+112 complete_all(&fw_st->completion);
+-------------------------------------------
+BTW,the double abort issue would not cause kernel panic or create an issue,
+but slow down it sometimes.The change is just a minor optimization.
+
+Signed-off-by: Junyong Sun <sunjunyong@xiaomi.com>
+Acked-by: Luis Chamberlain <mcgrof@kernel.org>
+Link: https://lore.kernel.org/r/1583202968-28792-1-git-send-email-sunjunyong@xiaomi.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/base/firmware_loader/fallback.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
+index 8704e1bae1758..1e9c96e3ed636 100644
+--- a/drivers/base/firmware_loader/fallback.c
++++ b/drivers/base/firmware_loader/fallback.c
+@@ -525,7 +525,7 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs,
+ }
+
+ retval = fw_sysfs_wait_timeout(fw_priv, timeout);
+- if (retval < 0) {
++ if (retval < 0 && retval != -ENOENT) {
+ mutex_lock(&fw_lock);
+ fw_load_abort(fw_sysfs);
+ mutex_unlock(&fw_lock);
+--
+2.20.1
+
--- /dev/null
+From 119852085c1dfd20746fbee16dadf931b46b4f00 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 Mar 2020 18:47:20 +0100
+Subject: genirq/irqdomain: Check pointer in irq_domain_alloc_irqs_hierarchy()
+
+From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
+
+[ Upstream commit 87f2d1c662fa1761359fdf558246f97e484d177a ]
+
+irq_domain_alloc_irqs_hierarchy() has 3 call sites in the compilation unit
+but only one of them checks for the pointer which is being dereferenced
+inside the called function. Move the check into the function. This allows
+for catching the error instead of the following crash:
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000000
+PC is at 0x0
+LR is at gpiochip_hierarchy_irq_domain_alloc+0x11f/0x140
+...
+[<c06c23ff>] (gpiochip_hierarchy_irq_domain_alloc)
+[<c0462a89>] (__irq_domain_alloc_irqs)
+[<c0462dad>] (irq_create_fwspec_mapping)
+[<c06c2251>] (gpiochip_to_irq)
+[<c06c1c9b>] (gpiod_to_irq)
+[<bf973073>] (gpio_irqs_init [gpio_irqs])
+[<bf974048>] (gpio_irqs_exit+0xecc/0xe84 [gpio_irqs])
+Code: bad PC value
+
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20200306174720.82604-1-alexander.sverdlin@nokia.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/irq/irqdomain.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
+index 7527e5ef6fe59..64507c663563f 100644
+--- a/kernel/irq/irqdomain.c
++++ b/kernel/irq/irqdomain.c
+@@ -1310,6 +1310,11 @@ int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
+ unsigned int irq_base,
+ unsigned int nr_irqs, void *arg)
+ {
++ if (!domain->ops->alloc) {
++ pr_debug("domain->ops->alloc() is NULL\n");
++ return -ENOSYS;
++ }
++
+ return domain->ops->alloc(domain, irq_base, nr_irqs, arg);
+ }
+
+@@ -1347,11 +1352,6 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
+ return -EINVAL;
+ }
+
+- if (!domain->ops->alloc) {
+- pr_debug("domain->ops->alloc() is NULL\n");
+- return -ENOSYS;
+- }
+-
+ if (realloc && irq_base >= 0) {
+ virq = irq_base;
+ } else {
+--
+2.20.1
+
--- /dev/null
+From 3ae6271827e6da4fc0b37da29d339a9e255aa317 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 13 Nov 2019 13:47:02 -0600
+Subject: gfs2: Do log_flush in gfs2_ail_empty_gl even if ail list is empty
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit 9ff78289356af640941bbb0dd3f46af2063f0046 ]
+
+Before this patch, if gfs2_ail_empty_gl saw there was nothing on
+the ail list, it would return and not flush the log. The problem
+is that there could still be a revoke for the rgrp sitting on the
+sd_log_le_revoke list that's been recently taken off the ail list.
+But that revoke still needs to be written, and the rgrp_go_inval
+still needs to call log_flush_wait to ensure the revokes are all
+properly written to the journal before we relinquish control of
+the glock to another node. If we give the glock to another node
+before we have this knowledge, the node might crash and its journal
+replayed, in which case the missing revoke would allow the journal
+replay to replay the rgrp over top of the rgrp we already gave to
+another node, thus overwriting its changes and corrupting the
+file system.
+
+This patch makes gfs2_ail_empty_gl still call gfs2_log_flush rather
+than returning.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/glops.c | 27 ++++++++++++++++++++++++++-
+ fs/gfs2/log.c | 2 +-
+ fs/gfs2/log.h | 1 +
+ 3 files changed, 28 insertions(+), 2 deletions(-)
+
+diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
+index 061d22e1ceb6e..efc899a3876b4 100644
+--- a/fs/gfs2/glops.c
++++ b/fs/gfs2/glops.c
+@@ -89,8 +89,32 @@ static void gfs2_ail_empty_gl(struct gfs2_glock *gl)
+ INIT_LIST_HEAD(&tr.tr_databuf);
+ tr.tr_revokes = atomic_read(&gl->gl_ail_count);
+
+- if (!tr.tr_revokes)
++ if (!tr.tr_revokes) {
++ bool have_revokes;
++ bool log_in_flight;
++
++ /*
++ * We have nothing on the ail, but there could be revokes on
++ * the sdp revoke queue, in which case, we still want to flush
++ * the log and wait for it to finish.
++ *
++ * If the sdp revoke list is empty too, we might still have an
++ * io outstanding for writing revokes, so we should wait for
++ * it before returning.
++ *
++ * If none of these conditions are true, our revokes are all
++ * flushed and we can return.
++ */
++ gfs2_log_lock(sdp);
++ have_revokes = !list_empty(&sdp->sd_log_revokes);
++ log_in_flight = atomic_read(&sdp->sd_log_in_flight);
++ gfs2_log_unlock(sdp);
++ if (have_revokes)
++ goto flush;
++ if (log_in_flight)
++ log_flush_wait(sdp);
+ return;
++ }
+
+ /* A shortened, inline version of gfs2_trans_begin()
+ * tr->alloced is not set since the transaction structure is
+@@ -105,6 +129,7 @@ static void gfs2_ail_empty_gl(struct gfs2_glock *gl)
+ __gfs2_ail_flush(gl, 0, tr.tr_revokes);
+
+ gfs2_trans_end(sdp);
++flush:
+ gfs2_log_flush(sdp, NULL, GFS2_LOG_HEAD_FLUSH_NORMAL |
+ GFS2_LFC_AIL_EMPTY_GL);
+ }
+diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
+index 00a2e721a374f..08dd6a4302344 100644
+--- a/fs/gfs2/log.c
++++ b/fs/gfs2/log.c
+@@ -512,7 +512,7 @@ static void log_pull_tail(struct gfs2_sbd *sdp, unsigned int new_tail)
+ }
+
+
+-static void log_flush_wait(struct gfs2_sbd *sdp)
++void log_flush_wait(struct gfs2_sbd *sdp)
+ {
+ DEFINE_WAIT(wait);
+
+diff --git a/fs/gfs2/log.h b/fs/gfs2/log.h
+index c0a65e5a126b6..c1cd6ae176597 100644
+--- a/fs/gfs2/log.h
++++ b/fs/gfs2/log.h
+@@ -73,6 +73,7 @@ extern void gfs2_log_flush(struct gfs2_sbd *sdp, struct gfs2_glock *gl,
+ u32 type);
+ extern void gfs2_log_commit(struct gfs2_sbd *sdp, struct gfs2_trans *trans);
+ extern void gfs2_ail1_flush(struct gfs2_sbd *sdp, struct writeback_control *wbc);
++extern void log_flush_wait(struct gfs2_sbd *sdp);
+
+ extern int gfs2_logd(void *data);
+ extern void gfs2_add_revoke(struct gfs2_sbd *sdp, struct gfs2_bufdata *bd);
+--
+2.20.1
+
--- /dev/null
+From 5e4af9883785f8a397970cfaad228b4d1271b36b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 13 Nov 2019 14:08:45 -0600
+Subject: gfs2: Don't demote a glock until its revokes are written
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+[ Upstream commit df5db5f9ee112e76b5202fbc331f990a0fc316d6 ]
+
+Before this patch, run_queue would demote glocks based on whether
+there are any more holders. But if the glock has pending revokes that
+haven't been written to the media, giving up the glock might end in
+file system corruption if the revokes never get written due to
+io errors, node crashes and fences, etc. In that case, another node
+will replay the metadata blocks associated with the glock, but
+because the revoke was never written, it could replay that block
+even though the glock had since been granted to another node who
+might have made changes.
+
+This patch changes the logic in run_queue so that it never demotes
+a glock until its count of pending revokes reaches zero.
+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/gfs2/glock.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
+index d0eceaff3cea9..19ebc6cd0f2ba 100644
+--- a/fs/gfs2/glock.c
++++ b/fs/gfs2/glock.c
+@@ -645,6 +645,9 @@ __acquires(&gl->gl_lockref.lock)
+ goto out_unlock;
+ if (nonblock)
+ goto out_sched;
++ smp_mb();
++ if (atomic_read(&gl->gl_revokes) != 0)
++ goto out_sched;
+ set_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags);
+ GLOCK_BUG_ON(gl, gl->gl_demote_state == LM_ST_EXCLUSIVE);
+ gl->gl_target = gl->gl_demote_state;
+--
+2.20.1
+
--- /dev/null
+From e77bb000cfbc1d27911b3428e2b9baa13d723695 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 13:37:54 +0100
+Subject: iio: imu: st_lsm6dsx: check return value from
+ st_lsm6dsx_sensor_set_enable
+
+From: Lorenzo Bianconi <lorenzo@kernel.org>
+
+[ Upstream commit f20dbe11e2e904547597ae7371c1f635e3be9cad ]
+
+Add missing return value check in st_lsm6dsx_shub_read_oneshot disabling
+the slave device connected to the st_lsm6dsx i2c controller.
+The issue is reported by coverity with the following error:
+
+Unchecked return value:
+If the function returns an error value, the error value may be mistaken
+for a normal value.
+
+Addresses-Coverity-ID: 1456767 ("Unchecked return value")
+Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
+index eea555617d4aa..95ddd19d1aa7c 100644
+--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
++++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
+@@ -464,9 +464,10 @@ st_lsm6dsx_shub_read_oneshot(struct st_lsm6dsx_sensor *sensor,
+
+ len = min_t(int, sizeof(data), ch->scan_type.realbits >> 3);
+ err = st_lsm6dsx_shub_read(sensor, ch->address, data, len);
++ if (err < 0)
++ return err;
+
+- st_lsm6dsx_shub_set_enable(sensor, false);
+-
++ err = st_lsm6dsx_shub_set_enable(sensor, false);
+ if (err < 0)
+ return err;
+
+--
+2.20.1
+
--- /dev/null
+From f85eb87c28a5eca849cc27bd96220e874aed8ffd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 18:49:21 +0000
+Subject: irqchip/gic-v4: Provide irq_retrigger to avoid circular locking
+ dependency
+
+From: Marc Zyngier <maz@kernel.org>
+
+[ Upstream commit 7809f7011c3bce650e502a98afeb05961470d865 ]
+
+On a very heavily loaded D05 with GICv4, I managed to trigger the
+following lockdep splat:
+
+[ 6022.598864] ======================================================
+[ 6022.605031] WARNING: possible circular locking dependency detected
+[ 6022.611200] 5.6.0-rc4-00026-geee7c7b0f498 #680 Tainted: G E
+[ 6022.618061] ------------------------------------------------------
+[ 6022.624227] qemu-system-aar/7569 is trying to acquire lock:
+[ 6022.629789] ffff042f97606808 (&p->pi_lock){-.-.}, at: try_to_wake_up+0x54/0x7a0
+[ 6022.637102]
+[ 6022.637102] but task is already holding lock:
+[ 6022.642921] ffff002fae424cf0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x5c/0x98
+[ 6022.651350]
+[ 6022.651350] which lock already depends on the new lock.
+[ 6022.651350]
+[ 6022.659512]
+[ 6022.659512] the existing dependency chain (in reverse order) is:
+[ 6022.666980]
+[ 6022.666980] -> #2 (&irq_desc_lock_class){-.-.}:
+[ 6022.672983] _raw_spin_lock_irqsave+0x50/0x78
+[ 6022.677848] __irq_get_desc_lock+0x5c/0x98
+[ 6022.682453] irq_set_vcpu_affinity+0x40/0xc0
+[ 6022.687236] its_make_vpe_non_resident+0x6c/0xb8
+[ 6022.692364] vgic_v4_put+0x54/0x70
+[ 6022.696273] vgic_v3_put+0x20/0xd8
+[ 6022.700183] kvm_vgic_put+0x30/0x48
+[ 6022.704182] kvm_arch_vcpu_put+0x34/0x50
+[ 6022.708614] kvm_sched_out+0x34/0x50
+[ 6022.712700] __schedule+0x4bc/0x7f8
+[ 6022.716697] schedule+0x50/0xd8
+[ 6022.720347] kvm_arch_vcpu_ioctl_run+0x5f0/0x978
+[ 6022.725473] kvm_vcpu_ioctl+0x3d4/0x8f8
+[ 6022.729820] ksys_ioctl+0x90/0xd0
+[ 6022.733642] __arm64_sys_ioctl+0x24/0x30
+[ 6022.738074] el0_svc_common.constprop.3+0xa8/0x1e8
+[ 6022.743373] do_el0_svc+0x28/0x88
+[ 6022.747198] el0_svc+0x14/0x40
+[ 6022.750761] el0_sync_handler+0x124/0x2b8
+[ 6022.755278] el0_sync+0x140/0x180
+[ 6022.759100]
+[ 6022.759100] -> #1 (&rq->lock){-.-.}:
+[ 6022.764143] _raw_spin_lock+0x38/0x50
+[ 6022.768314] task_fork_fair+0x40/0x128
+[ 6022.772572] sched_fork+0xe0/0x210
+[ 6022.776484] copy_process+0x8c4/0x18d8
+[ 6022.780742] _do_fork+0x88/0x6d8
+[ 6022.784478] kernel_thread+0x64/0x88
+[ 6022.788563] rest_init+0x30/0x270
+[ 6022.792390] arch_call_rest_init+0x14/0x1c
+[ 6022.796995] start_kernel+0x498/0x4c4
+[ 6022.801164]
+[ 6022.801164] -> #0 (&p->pi_lock){-.-.}:
+[ 6022.806382] __lock_acquire+0xdd8/0x15c8
+[ 6022.810813] lock_acquire+0xd0/0x218
+[ 6022.814896] _raw_spin_lock_irqsave+0x50/0x78
+[ 6022.819761] try_to_wake_up+0x54/0x7a0
+[ 6022.824018] wake_up_process+0x1c/0x28
+[ 6022.828276] wakeup_softirqd+0x38/0x40
+[ 6022.832533] __tasklet_schedule_common+0xc4/0xf0
+[ 6022.837658] __tasklet_schedule+0x24/0x30
+[ 6022.842176] check_irq_resend+0xc8/0x158
+[ 6022.846609] irq_startup+0x74/0x128
+[ 6022.850606] __enable_irq+0x6c/0x78
+[ 6022.854602] enable_irq+0x54/0xa0
+[ 6022.858431] its_make_vpe_non_resident+0xa4/0xb8
+[ 6022.863557] vgic_v4_put+0x54/0x70
+[ 6022.867469] kvm_arch_vcpu_blocking+0x28/0x38
+[ 6022.872336] kvm_vcpu_block+0x48/0x490
+[ 6022.876594] kvm_handle_wfx+0x18c/0x310
+[ 6022.880938] handle_exit+0x138/0x198
+[ 6022.885022] kvm_arch_vcpu_ioctl_run+0x4d4/0x978
+[ 6022.890148] kvm_vcpu_ioctl+0x3d4/0x8f8
+[ 6022.894494] ksys_ioctl+0x90/0xd0
+[ 6022.898317] __arm64_sys_ioctl+0x24/0x30
+[ 6022.902748] el0_svc_common.constprop.3+0xa8/0x1e8
+[ 6022.908046] do_el0_svc+0x28/0x88
+[ 6022.911871] el0_svc+0x14/0x40
+[ 6022.915434] el0_sync_handler+0x124/0x2b8
+[ 6022.919951] el0_sync+0x140/0x180
+[ 6022.923773]
+[ 6022.923773] other info that might help us debug this:
+[ 6022.923773]
+[ 6022.931762] Chain exists of:
+[ 6022.931762] &p->pi_lock --> &rq->lock --> &irq_desc_lock_class
+[ 6022.931762]
+[ 6022.942101] Possible unsafe locking scenario:
+[ 6022.942101]
+[ 6022.948007] CPU0 CPU1
+[ 6022.952523] ---- ----
+[ 6022.957039] lock(&irq_desc_lock_class);
+[ 6022.961036] lock(&rq->lock);
+[ 6022.966595] lock(&irq_desc_lock_class);
+[ 6022.973109] lock(&p->pi_lock);
+[ 6022.976324]
+[ 6022.976324] *** DEADLOCK ***
+
+This is happening because we have a pending doorbell that requires
+retrigger. As SW retriggering is done in a tasklet, we trigger the
+circular dependency above.
+
+The easy cop-out is to provide a retrigger callback that doesn't
+require acquiring any extra lock.
+
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200310184921.23552-5-maz@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
+index da883a6910284..7c8f65c9c32de 100644
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -3679,12 +3679,18 @@ static int its_vpe_set_irqchip_state(struct irq_data *d,
+ return 0;
+ }
+
++static int its_vpe_retrigger(struct irq_data *d)
++{
++ return !its_vpe_set_irqchip_state(d, IRQCHIP_STATE_PENDING, true);
++}
++
+ static struct irq_chip its_vpe_irq_chip = {
+ .name = "GICv4-vpe",
+ .irq_mask = its_vpe_mask_irq,
+ .irq_unmask = its_vpe_unmask_irq,
+ .irq_eoi = irq_chip_eoi_parent,
+ .irq_set_affinity = its_vpe_set_affinity,
++ .irq_retrigger = its_vpe_retrigger,
+ .irq_set_irqchip_state = its_vpe_set_irqchip_state,
+ .irq_set_vcpu_affinity = its_vpe_set_vcpu_affinity,
+ };
+--
+2.20.1
+
--- /dev/null
+From ecb0b0b13de80ac2e6b430335109dbbc5df88850 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 20:33:09 +0000
+Subject: irqchip/gic-v4.1: Skip absent CPUs while iterating over
+ redistributors
+
+From: Marc Zyngier <maz@kernel.org>
+
+[ Upstream commit 28d160de5194c68ff534443d2a8b6f1d10d57c58 ]
+
+In a system that is only sparsly populated with CPUs, we can end-up with
+redistributors structures that are not initialized. Let's make sure we
+don't try and access those when iterating over them (in this case when
+checking we have a L2 VPE table).
+
+Fixes: 4e6437f12d6e ("irqchip/gic-v4.1: Ensure L2 vPE table is allocated at RD level")
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
+Reviewed-by: Eric Auger <eric.auger@redhat.com>
+Link: https://lore.kernel.org/r/20200304203330.4967-3-maz@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
+index 83b1186ffcad0..da883a6910284 100644
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -2452,6 +2452,10 @@ static bool allocate_vpe_l2_table(int cpu, u32 id)
+ if (!gic_rdists->has_rvpeid)
+ return true;
+
++ /* Skip non-present CPUs */
++ if (!base)
++ return true;
++
+ val = gicr_read_vpropbaser(base + SZ_128K + GICR_VPROPBASER);
+
+ esz = FIELD_GET(GICR_VPROPBASER_4_1_ENTRY_SIZE, val) + 1;
+--
+2.20.1
+
--- /dev/null
+From 0ebb2451940e90b6db31bcd79a38f5d2fb9725d7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Mar 2020 11:34:48 +0900
+Subject: irqchip/versatile-fpga: Handle chained IRQs properly
+
+From: Sungbo Eo <mans0n@gorani.run>
+
+[ Upstream commit 486562da598c59e9f835b551d7cf19507de2d681 ]
+
+Enclose the chained handler with chained_irq_{enter,exit}(), so that the
+muxed interrupts get properly acked.
+
+This patch also fixes a reboot bug on OX820 SoC, where the jiffies timer
+interrupt is never acked. The kernel waits a clock tick forever in
+calibrate_delay_converge(), which leads to a boot hang.
+
+Fixes: c41b16f8c9d9 ("ARM: integrator/versatile: consolidate FPGA IRQ handling code")
+Signed-off-by: Sungbo Eo <mans0n@gorani.run>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200319023448.1479701-1-mans0n@gorani.run
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-versatile-fpga.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/irqchip/irq-versatile-fpga.c b/drivers/irqchip/irq-versatile-fpga.c
+index 928858dada756..70e2cfff8175f 100644
+--- a/drivers/irqchip/irq-versatile-fpga.c
++++ b/drivers/irqchip/irq-versatile-fpga.c
+@@ -6,6 +6,7 @@
+ #include <linux/irq.h>
+ #include <linux/io.h>
+ #include <linux/irqchip.h>
++#include <linux/irqchip/chained_irq.h>
+ #include <linux/irqchip/versatile-fpga.h>
+ #include <linux/irqdomain.h>
+ #include <linux/module.h>
+@@ -68,12 +69,16 @@ static void fpga_irq_unmask(struct irq_data *d)
+
+ static void fpga_irq_handle(struct irq_desc *desc)
+ {
++ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct fpga_irq_data *f = irq_desc_get_handler_data(desc);
+- u32 status = readl(f->base + IRQ_STATUS);
++ u32 status;
++
++ chained_irq_enter(chip, desc);
+
++ status = readl(f->base + IRQ_STATUS);
+ if (status == 0) {
+ do_bad_IRQ(desc);
+- return;
++ goto out;
+ }
+
+ do {
+@@ -82,6 +87,9 @@ static void fpga_irq_handle(struct irq_desc *desc)
+ status &= ~(1 << irq);
+ generic_handle_irq(irq_find_mapping(f->domain, irq));
+ } while (status);
++
++out:
++ chained_irq_exit(chip, desc);
+ }
+
+ /*
+--
+2.20.1
+
--- /dev/null
+From 6cd295174f55a6296ab3389ca3a9f50b69401ec1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Feb 2020 19:33:35 +0800
+Subject: libata: Remove extra scsi_host_put() in ata_scsi_add_hosts()
+
+From: John Garry <john.garry@huawei.com>
+
+[ Upstream commit 1d72f7aec3595249dbb83291ccac041a2d676c57 ]
+
+If the call to scsi_add_host_with_dma() in ata_scsi_add_hosts() fails,
+then we may get use-after-free KASAN warns:
+
+==================================================================
+BUG: KASAN: use-after-free in kobject_put+0x24/0x180
+Read of size 1 at addr ffff0026b8c80364 by task swapper/0/1
+CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-rc3-00004-g5a71b206ea82-dirty #1765
+Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B160.01 02/24/2020
+Call trace:
+dump_backtrace+0x0/0x298
+show_stack+0x14/0x20
+dump_stack+0x118/0x190
+print_address_description.isra.9+0x6c/0x3b8
+__kasan_report+0x134/0x23c
+kasan_report+0xc/0x18
+__asan_load1+0x5c/0x68
+kobject_put+0x24/0x180
+put_device+0x10/0x20
+scsi_host_put+0x10/0x18
+ata_devres_release+0x74/0xb0
+release_nodes+0x2d0/0x470
+devres_release_all+0x50/0x78
+really_probe+0x2d4/0x560
+driver_probe_device+0x7c/0x148
+device_driver_attach+0x94/0xa0
+__driver_attach+0xa8/0x110
+bus_for_each_dev+0xe8/0x158
+driver_attach+0x30/0x40
+bus_add_driver+0x220/0x2e0
+driver_register+0xbc/0x1d0
+__pci_register_driver+0xbc/0xd0
+ahci_pci_driver_init+0x20/0x28
+do_one_initcall+0xf0/0x608
+kernel_init_freeable+0x31c/0x384
+kernel_init+0x10/0x118
+ret_from_fork+0x10/0x18
+
+Allocated by task 5:
+save_stack+0x28/0xc8
+__kasan_kmalloc.isra.8+0xbc/0xd8
+kasan_kmalloc+0xc/0x18
+__kmalloc+0x1a8/0x280
+scsi_host_alloc+0x44/0x678
+ata_scsi_add_hosts+0x74/0x268
+ata_host_register+0x228/0x488
+ahci_host_activate+0x1c4/0x2a8
+ahci_init_one+0xd18/0x1298
+local_pci_probe+0x74/0xf0
+work_for_cpu_fn+0x2c/0x48
+process_one_work+0x488/0xc08
+worker_thread+0x330/0x5d0
+kthread+0x1c8/0x1d0
+ret_from_fork+0x10/0x18
+
+Freed by task 5:
+save_stack+0x28/0xc8
+__kasan_slab_free+0x118/0x180
+kasan_slab_free+0x10/0x18
+slab_free_freelist_hook+0xa4/0x1a0
+kfree+0xd4/0x3a0
+scsi_host_dev_release+0x100/0x148
+device_release+0x7c/0xe0
+kobject_put+0xb0/0x180
+put_device+0x10/0x20
+scsi_host_put+0x10/0x18
+ata_scsi_add_hosts+0x210/0x268
+ata_host_register+0x228/0x488
+ahci_host_activate+0x1c4/0x2a8
+ahci_init_one+0xd18/0x1298
+local_pci_probe+0x74/0xf0
+work_for_cpu_fn+0x2c/0x48
+process_one_work+0x488/0xc08
+worker_thread+0x330/0x5d0
+kthread+0x1c8/0x1d0
+ret_from_fork+0x10/0x18
+
+There is also refcount issue, as well:
+WARNING: CPU: 1 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x170
+
+The issue is that we make an erroneous extra call to scsi_host_put()
+for that host:
+
+So in ahci_init_one()->ata_host_alloc_pinfo()->ata_host_alloc(), we setup
+a device release method - ata_devres_release() - which intends to release
+the SCSI hosts:
+
+static void ata_devres_release(struct device *gendev, void *res)
+{
+ ...
+ for (i = 0; i < host->n_ports; i++) {
+ struct ata_port *ap = host->ports[i];
+
+ if (!ap)
+ continue;
+
+ if (ap->scsi_host)
+ scsi_host_put(ap->scsi_host);
+
+ }
+ ...
+}
+
+However in the ata_scsi_add_hosts() error path, we also call
+scsi_host_put() for the SCSI hosts.
+
+Fix by removing the the scsi_host_put() calls in ata_scsi_add_hosts() and
+leave this to ata_devres_release().
+
+Fixes: f31871951b38 ("libata: separate out ata_host_alloc() and ata_host_register()")
+Signed-off-by: John Garry <john.garry@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/libata-scsi.c | 9 +++------
+ 1 file changed, 3 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
+index eb2eb599e6023..061eebf85e6d2 100644
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -4562,22 +4562,19 @@ int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
+ */
+ shost->max_host_blocked = 1;
+
+- rc = scsi_add_host_with_dma(ap->scsi_host,
+- &ap->tdev, ap->host->dev);
++ rc = scsi_add_host_with_dma(shost, &ap->tdev, ap->host->dev);
+ if (rc)
+- goto err_add;
++ goto err_alloc;
+ }
+
+ return 0;
+
+- err_add:
+- scsi_host_put(host->ports[i]->scsi_host);
+ err_alloc:
+ while (--i >= 0) {
+ struct Scsi_Host *shost = host->ports[i]->scsi_host;
+
++ /* scsi_host_put() is in ata_devres_release() */
+ scsi_remove_host(shost);
+- scsi_host_put(shost);
+ }
+ return rc;
+ }
+--
+2.20.1
+
--- /dev/null
+From 8f63e020251d6e9a4046771662866a8ed5a6e90c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Mar 2020 23:12:55 +0800
+Subject: locking/lockdep: Avoid recursion in
+ lockdep_count_{for,back}ward_deps()
+
+From: Boqun Feng <boqun.feng@gmail.com>
+
+[ Upstream commit 25016bd7f4caf5fc983bbab7403d08e64cba3004 ]
+
+Qian Cai reported a bug when PROVE_RCU_LIST=y, and read on /proc/lockdep
+triggered a warning:
+
+ [ ] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
+ ...
+ [ ] Call Trace:
+ [ ] lock_is_held_type+0x5d/0x150
+ [ ] ? rcu_lockdep_current_cpu_online+0x64/0x80
+ [ ] rcu_read_lock_any_held+0xac/0x100
+ [ ] ? rcu_read_lock_held+0xc0/0xc0
+ [ ] ? __slab_free+0x421/0x540
+ [ ] ? kasan_kmalloc+0x9/0x10
+ [ ] ? __kmalloc_node+0x1d7/0x320
+ [ ] ? kvmalloc_node+0x6f/0x80
+ [ ] __bfs+0x28a/0x3c0
+ [ ] ? class_equal+0x30/0x30
+ [ ] lockdep_count_forward_deps+0x11a/0x1a0
+
+The warning got triggered because lockdep_count_forward_deps() call
+__bfs() without current->lockdep_recursion being set, as a result
+a lockdep internal function (__bfs()) is checked by lockdep, which is
+unexpected, and the inconsistency between the irq-off state and the
+state traced by lockdep caused the warning.
+
+Apart from this warning, lockdep internal functions like __bfs() should
+always be protected by current->lockdep_recursion to avoid potential
+deadlocks and data inconsistency, therefore add the
+current->lockdep_recursion on-and-off section to protect __bfs() in both
+lockdep_count_forward_deps() and lockdep_count_backward_deps()
+
+Reported-by: Qian Cai <cai@lca.pw>
+Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/20200312151258.128036-1-boqun.feng@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/locking/lockdep.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
+index 32406ef0d6a2d..5142a6b11bf5b 100644
+--- a/kernel/locking/lockdep.c
++++ b/kernel/locking/lockdep.c
+@@ -1719,9 +1719,11 @@ unsigned long lockdep_count_forward_deps(struct lock_class *class)
+ this.class = class;
+
+ raw_local_irq_save(flags);
++ current->lockdep_recursion = 1;
+ arch_spin_lock(&lockdep_lock);
+ ret = __lockdep_count_forward_deps(&this);
+ arch_spin_unlock(&lockdep_lock);
++ current->lockdep_recursion = 0;
+ raw_local_irq_restore(flags);
+
+ return ret;
+@@ -1746,9 +1748,11 @@ unsigned long lockdep_count_backward_deps(struct lock_class *class)
+ this.class = class;
+
+ raw_local_irq_save(flags);
++ current->lockdep_recursion = 1;
+ arch_spin_lock(&lockdep_lock);
+ ret = __lockdep_count_backward_deps(&this);
+ arch_spin_unlock(&lockdep_lock);
++ current->lockdep_recursion = 0;
+ raw_local_irq_restore(flags);
+
+ return ret;
+--
+2.20.1
+
--- /dev/null
+From 85cb1c5b5caa9d8f2415f10c72eaf9545204f987 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Feb 2020 11:10:04 +0100
+Subject: md: check arrays is suspended in mddev_detach before call quiesce
+ operations
+
+From: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
+
+[ Upstream commit 6b40bec3b13278d21fa6c1ae7a0bdf2e550eed5f ]
+
+Don't call quiesce(1) and quiesce(0) if array is already suspended,
+otherwise in level_store, the array is writable after mddev_detach
+in below part though the intention is to make array writable after
+resume.
+
+ mddev_suspend(mddev);
+ mddev_detach(mddev);
+ ...
+ mddev_resume(mddev);
+
+And it also causes calltrace as follows in [1].
+
+[48005.653834] WARNING: CPU: 1 PID: 45380 at kernel/kthread.c:510 kthread_park+0x77/0x90
+[...]
+[48005.653976] CPU: 1 PID: 45380 Comm: mdadm Tainted: G OE 5.4.10-arch1-1 #1
+[48005.653979] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4105-ITX, BIOS P1.40 08/06/2018
+[48005.653984] RIP: 0010:kthread_park+0x77/0x90
+[48005.654015] Call Trace:
+[48005.654039] r5l_quiesce+0x3c/0x70 [raid456]
+[48005.654052] raid5_quiesce+0x228/0x2e0 [raid456]
+[48005.654073] mddev_detach+0x30/0x70 [md_mod]
+[48005.654090] level_store+0x202/0x670 [md_mod]
+[48005.654099] ? security_capable+0x40/0x60
+[48005.654114] md_attr_store+0x7b/0xc0 [md_mod]
+[48005.654123] kernfs_fop_write+0xce/0x1b0
+[48005.654132] vfs_write+0xb6/0x1a0
+[48005.654138] ksys_write+0x67/0xe0
+[48005.654146] do_syscall_64+0x4e/0x140
+[48005.654155] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+[48005.654161] RIP: 0033:0x7fa0c8737497
+
+[1]: https://bugzilla.kernel.org/show_bug.cgi?id=206161
+
+Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
+Signed-off-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/md/md.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/md/md.c b/drivers/md/md.c
+index 469f551863bea..0b30ada971c14 100644
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -6184,7 +6184,7 @@ EXPORT_SYMBOL_GPL(md_stop_writes);
+ static void mddev_detach(struct mddev *mddev)
+ {
+ md_bitmap_wait_behind_writes(mddev);
+- if (mddev->pers && mddev->pers->quiesce) {
++ if (mddev->pers && mddev->pers->quiesce && !mddev->suspended) {
+ mddev->pers->quiesce(mddev, 1);
+ mddev->pers->quiesce(mddev, 0);
+ }
+--
+2.20.1
+
--- /dev/null
+From 3b5f755fa20c195449b90c1fa93e86add55a4588 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 16 Mar 2020 16:26:23 +0100
+Subject: media: allegro: fix type of gop_length in channel_create message
+
+From: Michael Tretter <m.tretter@pengutronix.de>
+
+[ Upstream commit 8277815349327b8e65226eb58ddb680f90c2c0c0 ]
+
+The gop_length field is actually only u16 and there are two more u8
+fields in the message:
+
+- the number of consecutive b-frames
+- frequency of golden frames
+
+Fix the message and thus fix the configuration of the GOP length.
+
+Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/allegro-dvt/allegro-core.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/staging/media/allegro-dvt/allegro-core.c b/drivers/staging/media/allegro-dvt/allegro-core.c
+index 3be41698df4c8..8d8d144f40ac2 100644
+--- a/drivers/staging/media/allegro-dvt/allegro-core.c
++++ b/drivers/staging/media/allegro-dvt/allegro-core.c
+@@ -393,7 +393,10 @@ struct mcu_msg_create_channel {
+ u32 freq_ird;
+ u32 freq_lt;
+ u32 gdr_mode;
+- u32 gop_length;
++ u16 gop_length;
++ u8 num_b;
++ u8 freq_golden_ref;
++
+ u32 unknown39;
+
+ u32 subframe_latency;
+--
+2.20.1
+
--- /dev/null
+From d7b71e08307f9362ec0ebb35e8ee8483ef9fac6a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 14 Feb 2020 09:58:02 +0100
+Subject: media: arm64: dts: amlogic: add rc-videostrong-kii-pro keymap
+
+From: Mohammad Rasim <mohammad.rasim96@gmail.com>
+
+[ Upstream commit 806d06161af045dba29f3c7747550c93b2ea3ca9 ]
+
+videostrong kii pro comes with a nec rc, add the keymap to the dts
+
+Signed-off-by: Mohammad Rasim <mohammad.rasim96@gmail.com>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
+index 2f1f829450a29..6c9cc45fb417e 100644
+--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
++++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
+@@ -76,3 +76,7 @@
+ };
+ };
+ };
++
++&ir {
++ linux,rc-map-name = "rc-videostrong-kii-pro";
++};
+--
+2.20.1
+
--- /dev/null
+From a45f9c8ba38ef40ac0a73fefe1c20d1a0e0ce3b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 27 Jan 2020 15:56:02 +0100
+Subject: media: hantro: fix extra MV/MC sync space calculation
+
+From: Philipp Zabel <p.zabel@pengutronix.de>
+
+[ Upstream commit 042584e9055b615ac917239884fb0d65690f56ec ]
+
+Add space for MVs and MC sync data to the capture buffers depending on
+whether the post processor will be enabled for the new capture format
+passed to TRY_FMT, not the currently set capture format.
+
+Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
+Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/hantro/hantro_v4l2.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
+index 0198bcda26b75..f4ae2cee0f189 100644
+--- a/drivers/staging/media/hantro/hantro_v4l2.c
++++ b/drivers/staging/media/hantro/hantro_v4l2.c
+@@ -295,7 +295,7 @@ static int vidioc_try_fmt(struct file *file, void *priv, struct v4l2_format *f,
+ * +---------------------------+
+ */
+ if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE &&
+- !hantro_needs_postproc(ctx, ctx->vpu_dst_fmt))
++ !hantro_needs_postproc(ctx, fmt))
+ pix_mp->plane_fmt[0].sizeimage +=
+ 64 * MB_WIDTH(pix_mp->width) *
+ MB_WIDTH(pix_mp->height) + 32;
+--
+2.20.1
+
--- /dev/null
+From 6d55cda87a025fdd4c221a916d47379617b01266 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 11 Mar 2020 11:47:28 +0100
+Subject: media: i2c: ov5695: Fix power on and off sequences
+
+From: Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+[ Upstream commit f1a64f56663e9d03e509439016dcbddd0166b2da ]
+
+From the measured hardware signal, OV5695 reset pin goes high for a
+short period of time during boot-up. From the sensor specification, the
+reset pin is active low and the DT binding defines the pin as active
+low, which means that the values set by the driver are inverted and thus
+the value requested in probe ends up high.
+
+Fix it by changing probe to request the reset GPIO initialized to high,
+which makes the initial state of the physical signal low.
+
+In addition, DOVDD rising must occur before DVDD rising from spec., but
+regulator_bulk_enable() API enables all the regulators asynchronously.
+Use an explicit loops of regulator_enable() instead.
+
+For power off sequence, it is required that DVDD falls first. Given the
+bulk API does not give any guarantee about the order of regulators,
+change the driver to use regulator_disable() instead.
+
+The sensor also requires a delay between reset high and first I2C
+transaction, which was assumed to be 8192 XVCLK cycles, but 1ms is
+recommended by the vendor. Fix this as well.
+
+Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
+Signed-off-by: Tomasz Figa <tfiga@chromium.org>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/i2c/ov5695.c | 49 ++++++++++++++++++++++++--------------
+ 1 file changed, 31 insertions(+), 18 deletions(-)
+
+diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c
+index d6cd15bb699ac..cc678d9d2e0da 100644
+--- a/drivers/media/i2c/ov5695.c
++++ b/drivers/media/i2c/ov5695.c
+@@ -971,16 +971,9 @@ unlock_and_return:
+ return ret;
+ }
+
+-/* Calculate the delay in us by clock rate and clock cycles */
+-static inline u32 ov5695_cal_delay(u32 cycles)
+-{
+- return DIV_ROUND_UP(cycles, OV5695_XVCLK_FREQ / 1000 / 1000);
+-}
+-
+ static int __ov5695_power_on(struct ov5695 *ov5695)
+ {
+- int ret;
+- u32 delay_us;
++ int i, ret;
+ struct device *dev = &ov5695->client->dev;
+
+ ret = clk_prepare_enable(ov5695->xvclk);
+@@ -991,21 +984,28 @@ static int __ov5695_power_on(struct ov5695 *ov5695)
+
+ gpiod_set_value_cansleep(ov5695->reset_gpio, 1);
+
+- ret = regulator_bulk_enable(OV5695_NUM_SUPPLIES, ov5695->supplies);
+- if (ret < 0) {
+- dev_err(dev, "Failed to enable regulators\n");
+- goto disable_clk;
++ /*
++ * The hardware requires the regulators to be powered on in order,
++ * so enable them one by one.
++ */
++ for (i = 0; i < OV5695_NUM_SUPPLIES; i++) {
++ ret = regulator_enable(ov5695->supplies[i].consumer);
++ if (ret) {
++ dev_err(dev, "Failed to enable %s: %d\n",
++ ov5695->supplies[i].supply, ret);
++ goto disable_reg_clk;
++ }
+ }
+
+ gpiod_set_value_cansleep(ov5695->reset_gpio, 0);
+
+- /* 8192 cycles prior to first SCCB transaction */
+- delay_us = ov5695_cal_delay(8192);
+- usleep_range(delay_us, delay_us * 2);
++ usleep_range(1000, 1200);
+
+ return 0;
+
+-disable_clk:
++disable_reg_clk:
++ for (--i; i >= 0; i--)
++ regulator_disable(ov5695->supplies[i].consumer);
+ clk_disable_unprepare(ov5695->xvclk);
+
+ return ret;
+@@ -1013,9 +1013,22 @@ disable_clk:
+
+ static void __ov5695_power_off(struct ov5695 *ov5695)
+ {
++ struct device *dev = &ov5695->client->dev;
++ int i, ret;
++
+ clk_disable_unprepare(ov5695->xvclk);
+ gpiod_set_value_cansleep(ov5695->reset_gpio, 1);
+- regulator_bulk_disable(OV5695_NUM_SUPPLIES, ov5695->supplies);
++
++ /*
++ * The hardware requires the regulators to be powered off in order,
++ * so disable them one by one.
++ */
++ for (i = OV5695_NUM_SUPPLIES - 1; i >= 0; i--) {
++ ret = regulator_disable(ov5695->supplies[i].consumer);
++ if (ret)
++ dev_err(dev, "Failed to disable %s: %d\n",
++ ov5695->supplies[i].supply, ret);
++ }
+ }
+
+ static int __maybe_unused ov5695_runtime_resume(struct device *dev)
+@@ -1285,7 +1298,7 @@ static int ov5695_probe(struct i2c_client *client,
+ if (clk_get_rate(ov5695->xvclk) != OV5695_XVCLK_FREQ)
+ dev_warn(dev, "xvclk mismatched, modes are based on 24MHz\n");
+
+- ov5695->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
++ ov5695->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ov5695->reset_gpio)) {
+ dev_err(dev, "Failed to get reset-gpios\n");
+ return -EINVAL;
+--
+2.20.1
+
--- /dev/null
+From 7b83169462c73d9dc4207af3179e8c044e957cae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 24 Mar 2020 02:07:41 +0100
+Subject: media: i2c: video-i2c: fix build errors due to 'imply hwmon'
+
+From: Matt Ranostay <matt.ranostay@konsulko.com>
+
+[ Upstream commit 64d4fc9926f09861a35d8f0f7d81f056e6d5af7b ]
+
+Fix build fault when CONFIG_HWMON is a module, and CONFIG_VIDEO_I2C
+as builtin. This is due to 'imply hwmon' in the respective Kconfig.
+
+Issue build log:
+
+ld: drivers/media/i2c/video-i2c.o: in function `amg88xx_hwmon_init':
+video-i2c.c:(.text+0x2e1): undefined reference to `devm_hwmon_device_register_with_info
+
+Cc: rdunlap@infradead.org
+Fixes: acbea6798955 (media: video-i2c: add hwmon support for amg88xx)
+Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/i2c/video-i2c.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
+index 078141712c887..0b977e73ceb29 100644
+--- a/drivers/media/i2c/video-i2c.c
++++ b/drivers/media/i2c/video-i2c.c
+@@ -255,7 +255,7 @@ static int amg88xx_set_power(struct video_i2c_data *data, bool on)
+ return amg88xx_set_power_off(data);
+ }
+
+-#if IS_ENABLED(CONFIG_HWMON)
++#if IS_REACHABLE(CONFIG_HWMON)
+
+ static const u32 amg88xx_temp_config[] = {
+ HWMON_T_INPUT,
+--
+2.20.1
+
--- /dev/null
+From 8fc87c5f8f2bfdb75805b3d96b52f797240761f3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 17:06:29 +0100
+Subject: media: imx: imx7-media-csi: Fix video field handling
+
+From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+[ Upstream commit f7b8488bd39ae8feced4dfbb41cf1431277b893f ]
+
+Commit 4791bd7d6adc ("media: imx: Try colorimetry at both sink and
+source pads") reworked the way that formats are set on the sink pad of
+the CSI subdevice, and accidentally removed video field handling.
+Restore it by defaulting to V4L2_FIELD_NONE if the field value isn't
+supported, with the only two supported value being V4L2_FIELD_NONE and
+V4L2_FIELD_INTERLACED.
+
+Fixes: 4791bd7d6adc ("media: imx: Try colorimetry at both sink and source pads")
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/imx/imx7-media-csi.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/staging/media/imx/imx7-media-csi.c b/drivers/staging/media/imx/imx7-media-csi.c
+index db30e2c70f2fe..f45920b3137e4 100644
+--- a/drivers/staging/media/imx/imx7-media-csi.c
++++ b/drivers/staging/media/imx/imx7-media-csi.c
+@@ -1009,6 +1009,7 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi,
+ sdformat->format.width = in_fmt->width;
+ sdformat->format.height = in_fmt->height;
+ sdformat->format.code = in_fmt->code;
++ sdformat->format.field = in_fmt->field;
+ *cc = in_cc;
+
+ sdformat->format.colorspace = in_fmt->colorspace;
+@@ -1023,6 +1024,9 @@ static int imx7_csi_try_fmt(struct imx7_csi *csi,
+ false);
+ sdformat->format.code = (*cc)->codes[0];
+ }
++
++ if (sdformat->format.field != V4L2_FIELD_INTERLACED)
++ sdformat->format.field = V4L2_FIELD_NONE;
+ break;
+ default:
+ return -EINVAL;
+--
+2.20.1
+
--- /dev/null
+From f64f4add0061e63e3ab2a120b63f93aa9fd83eb9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Mar 2020 17:06:24 +0100
+Subject: media: imx: imx7_mipi_csis: Power off the source when stopping
+ streaming
+
+From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+[ Upstream commit 770cbf89f90b0663499dbb3f03aa81b3322757ec ]
+
+The .s_stream() implementation incorrectly powers on the source when
+stopping the stream. Power it off instead.
+
+Fixes: 7807063b862b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7")
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/imx/imx7-mipi-csis.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
+index 383abecb3bec0..0053e8b0b88e5 100644
+--- a/drivers/staging/media/imx/imx7-mipi-csis.c
++++ b/drivers/staging/media/imx/imx7-mipi-csis.c
+@@ -577,7 +577,7 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
+ state->flags |= ST_STREAMING;
+ } else {
+ v4l2_subdev_call(state->src_sd, video, s_stream, 0);
+- ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
++ ret = v4l2_subdev_call(state->src_sd, core, s_power, 0);
+ mipi_csis_stop_stream(state);
+ state->flags &= ~ST_STREAMING;
+ if (state->debug)
+--
+2.20.1
+
--- /dev/null
+From 6f31790be104cb224f52e715e334a99a1f99814d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 03:58:51 +0100
+Subject: media: mtk-vpu: avoid unaligned access to DTCM buffer.
+
+From: Hsin-Yi Wang <hsinyi@chromium.org>
+
+[ Upstream commit e6599adfad30c340d06574e49a86afa7015c5c60 ]
+
+Previously, vpu->recv_buf and send_buf are forced cast from
+void __iomem *tcm. vpu->recv_buf->share_buf is passed to
+vpu_ipi_desc.handler(). It's not able to do unaligned access. Otherwise
+kernel would crash due to unable to handle kernel paging request.
+
+struct vpu_run {
+ u32 signaled;
+ char fw_ver[VPU_FW_VER_LEN];
+ unsigned int dec_capability;
+ unsigned int enc_capability;
+ wait_queue_head_t wq;
+};
+
+fw_ver starts at 4 byte boundary. If system enables
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, strscpy() will do
+read_word_at_a_time(), which tries to read 8-byte: *(unsigned long *)addr
+
+vpu_init_ipi_handler() calls strscpy(), which would lead to crash.
+
+vpu_init_ipi_handler() and several other handlers (eg.
+vpu_dec_ipi_handler) only do read access to this data, so they can be
+const, and we can use memcpy_fromio() to copy the buf to another non iomem
+buffer then pass to handler.
+
+Fixes: 85709cbf1524 ("media: replace strncpy() by strscpy()")
+Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 9 ++--
+ .../media/platform/mtk-vcodec/vdec_vpu_if.c | 6 +--
+ .../media/platform/mtk-vcodec/venc_vpu_if.c | 12 ++---
+ drivers/media/platform/mtk-vpu/mtk_vpu.c | 45 ++++++++++---------
+ drivers/media/platform/mtk-vpu/mtk_vpu.h | 2 +-
+ 5 files changed, 38 insertions(+), 36 deletions(-)
+
+diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
+index 6720d11f50cf6..b065ccd069140 100644
+--- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
++++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
+@@ -15,7 +15,7 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct mtk_mdp_vpu *vpu)
+ return container_of(vpu, struct mtk_mdp_ctx, vpu);
+ }
+
+-static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
++static void mtk_mdp_vpu_handle_init_ack(const struct mdp_ipi_comm_ack *msg)
+ {
+ struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)
+ (unsigned long)msg->ap_inst;
+@@ -26,10 +26,11 @@ static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
+ vpu->inst_addr = msg->vpu_inst_addr;
+ }
+
+-static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int len, void *priv)
++static void mtk_mdp_vpu_ipi_handler(const void *data, unsigned int len,
++ void *priv)
+ {
+- unsigned int msg_id = *(unsigned int *)data;
+- struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data;
++ const struct mdp_ipi_comm_ack *msg = data;
++ unsigned int msg_id = msg->msg_id;
+ struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)
+ (unsigned long)msg->ap_inst;
+ struct mtk_mdp_ctx *ctx;
+diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+index 70abfd4cd4b9f..948a12fd9d46a 100644
+--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
++++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+@@ -9,7 +9,7 @@
+ #include "vdec_ipi_msg.h"
+ #include "vdec_vpu_if.h"
+
+-static void handle_init_ack_msg(struct vdec_vpu_ipi_init_ack *msg)
++static void handle_init_ack_msg(const struct vdec_vpu_ipi_init_ack *msg)
+ {
+ struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
+ (unsigned long)msg->ap_inst_addr;
+@@ -34,9 +34,9 @@ static void handle_init_ack_msg(struct vdec_vpu_ipi_init_ack *msg)
+ * This function runs in interrupt context and it means there's an IPI MSG
+ * from VPU.
+ */
+-static void vpu_dec_ipi_handler(void *data, unsigned int len, void *priv)
++static void vpu_dec_ipi_handler(const void *data, unsigned int len, void *priv)
+ {
+- struct vdec_vpu_ipi_ack *msg = data;
++ const struct vdec_vpu_ipi_ack *msg = data;
+ struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
+ (unsigned long)msg->ap_inst_addr;
+
+diff --git a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+index 3e931b0ed0965..9540709c19058 100644
+--- a/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
++++ b/drivers/media/platform/mtk-vcodec/venc_vpu_if.c
+@@ -8,26 +8,26 @@
+ #include "venc_ipi_msg.h"
+ #include "venc_vpu_if.h"
+
+-static void handle_enc_init_msg(struct venc_vpu_inst *vpu, void *data)
++static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const void *data)
+ {
+- struct venc_vpu_ipi_msg_init *msg = data;
++ const struct venc_vpu_ipi_msg_init *msg = data;
+
+ vpu->inst_addr = msg->vpu_inst_addr;
+ vpu->vsi = vpu_mapping_dm_addr(vpu->dev, msg->vpu_inst_addr);
+ }
+
+-static void handle_enc_encode_msg(struct venc_vpu_inst *vpu, void *data)
++static void handle_enc_encode_msg(struct venc_vpu_inst *vpu, const void *data)
+ {
+- struct venc_vpu_ipi_msg_enc *msg = data;
++ const struct venc_vpu_ipi_msg_enc *msg = data;
+
+ vpu->state = msg->state;
+ vpu->bs_size = msg->bs_size;
+ vpu->is_key_frm = msg->is_key_frm;
+ }
+
+-static void vpu_enc_ipi_handler(void *data, unsigned int len, void *priv)
++static void vpu_enc_ipi_handler(const void *data, unsigned int len, void *priv)
+ {
+- struct venc_vpu_ipi_msg_common *msg = data;
++ const struct venc_vpu_ipi_msg_common *msg = data;
+ struct venc_vpu_inst *vpu =
+ (struct venc_vpu_inst *)(unsigned long)msg->venc_inst;
+
+diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
+index a768707abb942..2fbccc9b247b0 100644
+--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
++++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
+@@ -203,8 +203,8 @@ struct mtk_vpu {
+ struct vpu_run run;
+ struct vpu_wdt wdt;
+ struct vpu_ipi_desc ipi_desc[IPI_MAX];
+- struct share_obj *recv_buf;
+- struct share_obj *send_buf;
++ struct share_obj __iomem *recv_buf;
++ struct share_obj __iomem *send_buf;
+ struct device *dev;
+ struct clk *clk;
+ bool fw_loaded;
+@@ -292,7 +292,7 @@ int vpu_ipi_send(struct platform_device *pdev,
+ unsigned int len)
+ {
+ struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+- struct share_obj *send_obj = vpu->send_buf;
++ struct share_obj __iomem *send_obj = vpu->send_buf;
+ unsigned long timeout;
+ int ret = 0;
+
+@@ -325,9 +325,9 @@ int vpu_ipi_send(struct platform_device *pdev,
+ }
+ } while (vpu_cfg_readl(vpu, HOST_TO_VPU));
+
+- memcpy((void *)send_obj->share_buf, buf, len);
+- send_obj->len = len;
+- send_obj->id = id;
++ memcpy_toio(send_obj->share_buf, buf, len);
++ writel(len, &send_obj->len);
++ writel(id, &send_obj->id);
+
+ vpu->ipi_id_ack[id] = false;
+ /* send the command to VPU */
+@@ -600,10 +600,10 @@ OUT_LOAD_FW:
+ }
+ EXPORT_SYMBOL_GPL(vpu_load_firmware);
+
+-static void vpu_init_ipi_handler(void *data, unsigned int len, void *priv)
++static void vpu_init_ipi_handler(const void *data, unsigned int len, void *priv)
+ {
+- struct mtk_vpu *vpu = (struct mtk_vpu *)priv;
+- struct vpu_run *run = (struct vpu_run *)data;
++ struct mtk_vpu *vpu = priv;
++ const struct vpu_run *run = data;
+
+ vpu->run.signaled = run->signaled;
+ strscpy(vpu->run.fw_ver, run->fw_ver, sizeof(vpu->run.fw_ver));
+@@ -700,19 +700,21 @@ static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
+
+ static void vpu_ipi_handler(struct mtk_vpu *vpu)
+ {
+- struct share_obj *rcv_obj = vpu->recv_buf;
++ struct share_obj __iomem *rcv_obj = vpu->recv_buf;
+ struct vpu_ipi_desc *ipi_desc = vpu->ipi_desc;
+-
+- if (rcv_obj->id < IPI_MAX && ipi_desc[rcv_obj->id].handler) {
+- ipi_desc[rcv_obj->id].handler(rcv_obj->share_buf,
+- rcv_obj->len,
+- ipi_desc[rcv_obj->id].priv);
+- if (rcv_obj->id > IPI_VPU_INIT) {
+- vpu->ipi_id_ack[rcv_obj->id] = true;
++ unsigned char data[SHARE_BUF_SIZE];
++ s32 id = readl(&rcv_obj->id);
++
++ memcpy_fromio(data, rcv_obj->share_buf, sizeof(data));
++ if (id < IPI_MAX && ipi_desc[id].handler) {
++ ipi_desc[id].handler(data, readl(&rcv_obj->len),
++ ipi_desc[id].priv);
++ if (id > IPI_VPU_INIT) {
++ vpu->ipi_id_ack[id] = true;
+ wake_up(&vpu->ack_wq);
+ }
+ } else {
+- dev_err(vpu->dev, "No such ipi id = %d\n", rcv_obj->id);
++ dev_err(vpu->dev, "No such ipi id = %d\n", id);
+ }
+ }
+
+@@ -722,11 +724,10 @@ static int vpu_ipi_init(struct mtk_vpu *vpu)
+ vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
+
+ /* shared buffer initialization */
+- vpu->recv_buf = (__force struct share_obj *)(vpu->reg.tcm +
+- VPU_DTCM_OFFSET);
++ vpu->recv_buf = vpu->reg.tcm + VPU_DTCM_OFFSET;
+ vpu->send_buf = vpu->recv_buf + 1;
+- memset(vpu->recv_buf, 0, sizeof(struct share_obj));
+- memset(vpu->send_buf, 0, sizeof(struct share_obj));
++ memset_io(vpu->recv_buf, 0, sizeof(struct share_obj));
++ memset_io(vpu->send_buf, 0, sizeof(struct share_obj));
+
+ return 0;
+ }
+diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h b/drivers/media/platform/mtk-vpu/mtk_vpu.h
+index d4453b4bcee92..ee7c552ce9289 100644
+--- a/drivers/media/platform/mtk-vpu/mtk_vpu.h
++++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
+@@ -15,7 +15,7 @@
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+-typedef void (*ipi_handler_t) (void *data,
++typedef void (*ipi_handler_t) (const void *data,
+ unsigned int len,
+ void *priv);
+
+--
+2.20.1
+
--- /dev/null
+From 9e0276736bf1056c31fe9a7455d78fb43a12186e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 10 Jan 2020 17:25:45 +0100
+Subject: media: rc: add keymap for Videostrong KII Pro
+
+From: Mohammad Rasim <mohammad.rasim96@gmail.com>
+
+[ Upstream commit 30defecb98400575349a7d32f0526e1dc42ea83e ]
+
+This is an NEC remote control device shipped with the Videostrong KII Pro
+tv box as well as other devices from videostrong.
+
+Signed-off-by: Mohammad Rasim <mohammad.rasim96@gmail.com>
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/rc/keymaps/Makefile | 1 +
+ .../media/rc/keymaps/rc-videostrong-kii-pro.c | 83 +++++++++++++++++++
+ include/media/rc-map.h | 1 +
+ 3 files changed, 85 insertions(+)
+ create mode 100644 drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
+
+diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile
+index 63261ef6380a9..aaa1bf81d00d4 100644
+--- a/drivers/media/rc/keymaps/Makefile
++++ b/drivers/media/rc/keymaps/Makefile
+@@ -119,6 +119,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
+ rc-videomate-m1f.o \
+ rc-videomate-s350.o \
+ rc-videomate-tv-pvr.o \
++ rc-videostrong-kii-pro.o \
+ rc-wetek-hub.o \
+ rc-wetek-play2.o \
+ rc-winfast.o \
+diff --git a/drivers/media/rc/keymaps/rc-videostrong-kii-pro.c b/drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
+new file mode 100644
+index 0000000000000..414d4d231e7ed
+--- /dev/null
++++ b/drivers/media/rc/keymaps/rc-videostrong-kii-pro.c
+@@ -0,0 +1,83 @@
++// SPDX-License-Identifier: GPL-2.0+
++//
++// Copyright (C) 2019 Mohammad Rasim <mohammad.rasim96@gmail.com>
++
++#include <media/rc-map.h>
++#include <linux/module.h>
++
++//
++// Keytable for the Videostrong KII Pro STB remote control
++//
++
++static struct rc_map_table kii_pro[] = {
++ { 0x59, KEY_POWER },
++ { 0x19, KEY_MUTE },
++ { 0x42, KEY_RED },
++ { 0x40, KEY_GREEN },
++ { 0x00, KEY_YELLOW },
++ { 0x03, KEY_BLUE },
++ { 0x4a, KEY_BACK },
++ { 0x48, KEY_FORWARD },
++ { 0x08, KEY_PREVIOUSSONG},
++ { 0x0b, KEY_NEXTSONG},
++ { 0x46, KEY_PLAYPAUSE },
++ { 0x44, KEY_STOP },
++ { 0x1f, KEY_FAVORITES}, //KEY_F5?
++ { 0x04, KEY_PVR },
++ { 0x4d, KEY_EPG },
++ { 0x02, KEY_INFO },
++ { 0x09, KEY_SUBTITLE },
++ { 0x01, KEY_AUDIO },
++ { 0x0d, KEY_HOMEPAGE },
++ { 0x11, KEY_TV }, // DTV ?
++ { 0x06, KEY_UP },
++ { 0x5a, KEY_LEFT },
++ { 0x1a, KEY_ENTER }, // KEY_OK ?
++ { 0x1b, KEY_RIGHT },
++ { 0x16, KEY_DOWN },
++ { 0x45, KEY_MENU },
++ { 0x05, KEY_ESC },
++ { 0x13, KEY_VOLUMEUP },
++ { 0x17, KEY_VOLUMEDOWN },
++ { 0x58, KEY_APPSELECT },
++ { 0x12, KEY_VENDOR }, // mouse
++ { 0x55, KEY_PAGEUP }, // KEY_CHANNELUP ?
++ { 0x15, KEY_PAGEDOWN }, // KEY_CHANNELDOWN ?
++ { 0x52, KEY_1 },
++ { 0x50, KEY_2 },
++ { 0x10, KEY_3 },
++ { 0x56, KEY_4 },
++ { 0x54, KEY_5 },
++ { 0x14, KEY_6 },
++ { 0x4e, KEY_7 },
++ { 0x4c, KEY_8 },
++ { 0x0c, KEY_9 },
++ { 0x18, KEY_WWW }, // KEY_F7
++ { 0x0f, KEY_0 },
++ { 0x51, KEY_BACKSPACE },
++};
++
++static struct rc_map_list kii_pro_map = {
++ .map = {
++ .scan = kii_pro,
++ .size = ARRAY_SIZE(kii_pro),
++ .rc_proto = RC_PROTO_NEC,
++ .name = RC_MAP_KII_PRO,
++ }
++};
++
++static int __init init_rc_map_kii_pro(void)
++{
++ return rc_map_register(&kii_pro_map);
++}
++
++static void __exit exit_rc_map_kii_pro(void)
++{
++ rc_map_unregister(&kii_pro_map);
++}
++
++module_init(init_rc_map_kii_pro)
++module_exit(exit_rc_map_kii_pro)
++
++MODULE_LICENSE("GPL");
++MODULE_AUTHOR("Mohammad Rasim <mohammad.rasim96@gmail.com>");
+diff --git a/include/media/rc-map.h b/include/media/rc-map.h
+index f99575a0d29c8..d22810dcd85c6 100644
+--- a/include/media/rc-map.h
++++ b/include/media/rc-map.h
+@@ -274,6 +274,7 @@ struct rc_map *rc_map_get(const char *name);
+ #define RC_MAP_VIDEOMATE_K100 "rc-videomate-k100"
+ #define RC_MAP_VIDEOMATE_S350 "rc-videomate-s350"
+ #define RC_MAP_VIDEOMATE_TV_PVR "rc-videomate-tv-pvr"
++#define RC_MAP_KII_PRO "rc-videostrong-kii-pro"
+ #define RC_MAP_WETEK_HUB "rc-wetek-hub"
+ #define RC_MAP_WETEK_PLAY2 "rc-wetek-play2"
+ #define RC_MAP_WINFAST "rc-winfast"
+--
+2.20.1
+
--- /dev/null
+From bb388f74e8b004f3744f06119a97fc928dc87cbd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 6 Feb 2020 23:07:12 +0100
+Subject: media: staging: rkisp1: isp: do not set invalid mbus code for pad
+
+From: Helen Koike <helen.koike@collabora.com>
+
+[ Upstream commit 100f720aabab3d5f58f67c508186041b3c797a9b ]
+
+When setting source pad, check if the given mbus code is indeed valid
+for source pad, if not, then set the default code.
+Same for sink pad.
+
+Fixes: d65dd85281fb ("media: staging: rkisp1: add Rockchip ISP1 base driver")
+Reported-by: Wojciech Zabolotny <wzab01@gmail.com>
+Signed-off-by: Helen Koike <helen.koike@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/rkisp1/rkisp1-isp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/staging/media/rkisp1/rkisp1-isp.c b/drivers/staging/media/rkisp1/rkisp1-isp.c
+index 328c7ea609717..db892620a5675 100644
+--- a/drivers/staging/media/rkisp1/rkisp1-isp.c
++++ b/drivers/staging/media/rkisp1/rkisp1-isp.c
+@@ -683,7 +683,7 @@ static void rkisp1_isp_set_src_fmt(struct rkisp1_isp *isp,
+
+ src_fmt->code = format->code;
+ mbus_info = rkisp1_isp_mbus_info_get(src_fmt->code);
+- if (!mbus_info) {
++ if (!mbus_info || !(mbus_info->direction & RKISP1_DIR_SRC)) {
+ src_fmt->code = RKISP1_DEF_SRC_PAD_FMT;
+ mbus_info = rkisp1_isp_mbus_info_get(src_fmt->code);
+ }
+@@ -767,7 +767,7 @@ static void rkisp1_isp_set_sink_fmt(struct rkisp1_isp *isp,
+ which);
+ sink_fmt->code = format->code;
+ mbus_info = rkisp1_isp_mbus_info_get(sink_fmt->code);
+- if (!mbus_info) {
++ if (!mbus_info || !(mbus_info->direction & RKISP1_DIR_SINK)) {
+ sink_fmt->code = RKISP1_DEF_SINK_PAD_FMT;
+ mbus_info = rkisp1_isp_mbus_info_get(sink_fmt->code);
+ }
+--
+2.20.1
+
--- /dev/null
+From 5fdae775e2b8cc82fab8a1d4d396271bb59eda59 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 6 Feb 2020 23:07:08 +0100
+Subject: media: staging: rkisp1: use consistent bus_info string for media_dev
+
+From: Helen Koike <helen.koike@collabora.com>
+
+[ Upstream commit 12d3d8090bc5e8cdda2f56caed2a2a0d70009456 ]
+
+Media device is using a slightly different bus_info string
+"platform: rkisp1" (with a space) instead of "platform:rkisp1" used by
+the rest of rkisp1 code.
+This causes errors when using v4l2-util tools that uses the bus_info
+string to identify the device.
+
+Fixes: d65dd85281fb ("media: staging: rkisp1: add Rockchip ISP1 base driver")
+Signed-off-by: Helen Koike <helen.koike@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/media/rkisp1/rkisp1-dev.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/staging/media/rkisp1/rkisp1-dev.c b/drivers/staging/media/rkisp1/rkisp1-dev.c
+index 558126e66465c..9b47f41b36e94 100644
+--- a/drivers/staging/media/rkisp1/rkisp1-dev.c
++++ b/drivers/staging/media/rkisp1/rkisp1-dev.c
+@@ -502,8 +502,7 @@ static int rkisp1_probe(struct platform_device *pdev)
+ strscpy(rkisp1->media_dev.model, RKISP1_DRIVER_NAME,
+ sizeof(rkisp1->media_dev.model));
+ rkisp1->media_dev.dev = &pdev->dev;
+- strscpy(rkisp1->media_dev.bus_info,
+- "platform: " RKISP1_DRIVER_NAME,
++ strscpy(rkisp1->media_dev.bus_info, RKISP1_BUS_INFO,
+ sizeof(rkisp1->media_dev.bus_info));
+ media_device_init(&rkisp1->media_dev);
+
+--
+2.20.1
+
--- /dev/null
+From d3692b921990ad8762d0f861d17e6a85e677a263 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Dec 2019 20:16:52 +0100
+Subject: media: venus: hfi_parser: Ignore HEVC encoding for V1
+
+From: Stephan Gerhold <stephan@gerhold.net>
+
+[ Upstream commit c50cc6dc6c48300af63a6fbc71b647053c15fc80 ]
+
+Some older MSM8916 Venus firmware versions also seem to indicate
+support for encoding HEVC, even though they really can't.
+This will lead to errors later because hfi_session_init() fails
+in this case.
+
+HEVC is already ignored for "dec_codecs", so add the same for
+"enc_codecs" to make these old firmware versions work correctly.
+
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/platform/qcom/venus/hfi_parser.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/media/platform/qcom/venus/hfi_parser.c b/drivers/media/platform/qcom/venus/hfi_parser.c
+index 2293d936e49ca..7f515a4b9bd12 100644
+--- a/drivers/media/platform/qcom/venus/hfi_parser.c
++++ b/drivers/media/platform/qcom/venus/hfi_parser.c
+@@ -181,6 +181,7 @@ static void parse_codecs(struct venus_core *core, void *data)
+ if (IS_V1(core)) {
+ core->dec_codecs &= ~HFI_VIDEO_CODEC_HEVC;
+ core->dec_codecs &= ~HFI_VIDEO_CODEC_SPARK;
++ core->enc_codecs &= ~HFI_VIDEO_CODEC_HEVC;
+ }
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 3e2f9b69f753e6e50dc94e4961c45c0ef86a5e08 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Jan 2020 19:59:33 +0100
+Subject: media: vimc: streamer: fix memory leak in vimc subdevs if kthread_run
+ fails
+
+From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
+
+[ Upstream commit ceeb2e6166dddf3c9757abbbf84032027e2fa2d2 ]
+
+In case kthread_run fails, the vimc subdevices
+should be notified that streaming stopped so they can
+release the memory for the streaming. Also, kthread should be
+set to NULL.
+
+Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
+Acked-by: Helen Koike <helen.koike@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/platform/vimc/vimc-streamer.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/media/platform/vimc/vimc-streamer.c b/drivers/media/platform/vimc/vimc-streamer.c
+index cd6b55433c9ee..43e494df61d88 100644
+--- a/drivers/media/platform/vimc/vimc-streamer.c
++++ b/drivers/media/platform/vimc/vimc-streamer.c
+@@ -207,8 +207,13 @@ int vimc_streamer_s_stream(struct vimc_stream *stream,
+ stream->kthread = kthread_run(vimc_streamer_thread, stream,
+ "vimc-streamer thread");
+
+- if (IS_ERR(stream->kthread))
+- return PTR_ERR(stream->kthread);
++ if (IS_ERR(stream->kthread)) {
++ ret = PTR_ERR(stream->kthread);
++ dev_err(ved->dev, "kthread_run failed with %d\n", ret);
++ vimc_streamer_pipeline_terminate(stream);
++ stream->kthread = NULL;
++ return ret;
++ }
+
+ } else {
+ if (!stream->kthread)
+--
+2.20.1
+
--- /dev/null
+From 8053e601dfe4b21b9d608a0788977bf298298dcd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Feb 2020 23:23:20 +0300
+Subject: null_blk: fix spurious IO errors after failed past-wp access
+
+From: Alexey Dobriyan <adobriyan@gmail.com>
+
+[ Upstream commit ff77042296d0a54535ddf74412c5ae92cb4ec76a ]
+
+Steps to reproduce:
+
+ BLKRESETZONE zone 0
+
+ // force EIO
+ pwrite(fd, buf, 4096, 4096);
+
+ [issue more IO including zone ioctls]
+
+It will start failing randomly including IO to unrelated zones because of
+->error "reuse". Trigger can be partition detection as well if test is not
+run immediately which is even more entertaining.
+
+The fix is of course to clear ->error where necessary.
+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Alexey Dobriyan (SK hynix) <adobriyan@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index 2b8b4cb447cfb..d6a8d66e98036 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -605,6 +605,7 @@ static struct nullb_cmd *__alloc_cmd(struct nullb_queue *nq)
+ if (tag != -1U) {
+ cmd = &nq->cmds[tag];
+ cmd->tag = tag;
++ cmd->error = BLK_STS_OK;
+ cmd->nq = nq;
+ if (nq->dev->irqmode == NULL_IRQ_TIMER) {
+ hrtimer_init(&cmd->timer, CLOCK_MONOTONIC,
+@@ -1385,6 +1386,7 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx *hctx,
+ cmd->timer.function = null_cmd_timer_expired;
+ }
+ cmd->rq = bd->rq;
++ cmd->error = BLK_STS_OK;
+ cmd->nq = nq;
+
+ blk_mq_start_request(bd->rq);
+--
+2.20.1
+
--- /dev/null
+From f199dd438a80cd17dd5f527ad1c65365db75c94b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 21:26:21 -0700
+Subject: null_blk: Fix the null_add_dev() error path
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit 2004bfdef945fe55196db6b9cdf321fbc75bb0de ]
+
+If null_add_dev() fails, clear dev->nullb.
+
+This patch fixes the following KASAN complaint:
+
+BUG: KASAN: use-after-free in nullb_device_submit_queues_store+0xcf/0x160 [null_blk]
+Read of size 8 at addr ffff88803280fc30 by task check/8409
+
+Call Trace:
+ dump_stack+0xa5/0xe6
+ print_address_description.constprop.0+0x26/0x260
+ __kasan_report.cold+0x7b/0x99
+ kasan_report+0x16/0x20
+ __asan_load8+0x58/0x90
+ nullb_device_submit_queues_store+0xcf/0x160 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+RIP: 0033:0x7ff370926317
+Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
+RSP: 002b:00007fff2dd2da48 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007ff370926317
+RDX: 0000000000000002 RSI: 0000559437ef23f0 RDI: 0000000000000001
+RBP: 0000559437ef23f0 R08: 000000000000000a R09: 0000000000000001
+R10: 0000559436703471 R11: 0000000000000246 R12: 0000000000000002
+R13: 00007ff370a006a0 R14: 00007ff370a014a0 R15: 00007ff370a008a0
+
+Allocated by task 8409:
+ save_stack+0x23/0x90
+ __kasan_kmalloc.constprop.0+0xcf/0xe0
+ kasan_kmalloc+0xd/0x10
+ kmem_cache_alloc_node_trace+0x129/0x4c0
+ null_add_dev+0x24a/0xe90 [null_blk]
+ nullb_device_power_store+0x1b6/0x270 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Freed by task 8409:
+ save_stack+0x23/0x90
+ __kasan_slab_free+0x112/0x160
+ kasan_slab_free+0x12/0x20
+ kfree+0xdf/0x250
+ null_add_dev+0xaf3/0xe90 [null_blk]
+ nullb_device_power_store+0x1b6/0x270 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Fixes: 2984c8684f96 ("nullb: factor disk parameters")
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
+Cc: Johannes Thumshirn <jth@kernel.org>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index 133060431dbdb..8ada43b3eca13 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -1788,6 +1788,7 @@ out_cleanup_queues:
+ cleanup_queues(nullb);
+ out_free_nullb:
+ kfree(nullb);
++ dev->nullb = NULL;
+ out:
+ return rv;
+ }
+--
+2.20.1
+
--- /dev/null
+From 25ae525ad384bd2aeda148cb4ef3460d73a2e358 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 21:26:22 -0700
+Subject: null_blk: Handle null_add_dev() failures properly
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit 9b03b713082a31a5b90e0a893c72aa620e255c26 ]
+
+If null_add_dev() fails then null_del_dev() is called with a NULL argument.
+Make null_del_dev() handle this scenario correctly. This patch fixes the
+following KASAN complaint:
+
+null-ptr-deref in null_del_dev+0x28/0x280 [null_blk]
+Read of size 8 at addr 0000000000000000 by task find/1062
+
+Call Trace:
+ dump_stack+0xa5/0xe6
+ __kasan_report.cold+0x65/0x99
+ kasan_report+0x16/0x20
+ __asan_load8+0x58/0x90
+ null_del_dev+0x28/0x280 [null_blk]
+ nullb_group_drop_item+0x7e/0xa0 [null_blk]
+ client_drop_item+0x53/0x80 [configfs]
+ configfs_rmdir+0x395/0x4e0 [configfs]
+ vfs_rmdir+0xb6/0x220
+ do_rmdir+0x238/0x2c0
+ __x64_sys_unlinkat+0x75/0x90
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
+Cc: Johannes Thumshirn <jth@kernel.org>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index 8ada43b3eca13..d5b4a92033d48 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -1432,7 +1432,12 @@ static void cleanup_queues(struct nullb *nullb)
+
+ static void null_del_dev(struct nullb *nullb)
+ {
+- struct nullb_device *dev = nullb->dev;
++ struct nullb_device *dev;
++
++ if (!nullb)
++ return;
++
++ dev = nullb->dev;
+
+ ida_simple_remove(&nullb_indexes, nullb->index);
+
+--
+2.20.1
+
--- /dev/null
+From 756af25c1b8ef7decd5fdc54c8ada63bc712f2b6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 21:26:19 -0700
+Subject: null_blk: Suppress an UBSAN complaint triggered when setting
+ 'memory_backed'
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+[ Upstream commit b9853b4d6fb403ccb1d4d82e2d39fc17fc07519c ]
+
+Although it is not clear to me why UBSAN complains when 'memory_backed'
+is set, this patch suppresses the UBSAN complaint that is triggered when
+setting that configfs attribute.
+
+UBSAN: Undefined behaviour in drivers/block/null_blk_main.c:327:1
+load of value 16 is not a valid value for type '_Bool'
+CPU: 2 PID: 8396 Comm: check Not tainted 5.6.0-rc1-dbg+ #14
+Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
+Call Trace:
+ dump_stack+0xa5/0xe6
+ ubsan_epilogue+0x9/0x26
+ __ubsan_handle_load_invalid_value+0x6d/0x76
+ nullb_device_memory_backed_store.cold+0x2c/0x38 [null_blk]
+ configfs_write_file+0x1c4/0x250 [configfs]
+ __vfs_write+0x4c/0x90
+ vfs_write+0x145/0x2c0
+ ksys_write+0xd7/0x180
+ __x64_sys_write+0x47/0x50
+ do_syscall_64+0x6f/0x2f0
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
+Cc: Johannes Thumshirn <jth@kernel.org>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Ming Lei <ming.lei@redhat.com>
+Cc: Christoph Hellwig <hch@infradead.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/null_blk_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
+index d5b4a92033d48..2b8b4cb447cfb 100644
+--- a/drivers/block/null_blk_main.c
++++ b/drivers/block/null_blk_main.c
+@@ -276,7 +276,7 @@ nullb_device_##NAME##_store(struct config_item *item, const char *page, \
+ { \
+ int (*apply_fn)(struct nullb_device *dev, TYPE new_value) = APPLY;\
+ struct nullb_device *dev = to_nullb_device(item); \
+- TYPE uninitialized_var(new_value); \
++ TYPE new_value = 0; \
+ int ret; \
+ \
+ ret = nullb_device_##TYPE##_attr_store(&new_value, page, count);\
+--
+2.20.1
+
--- /dev/null
+From 388b9bee250587d7276bdde41b48080aeace6c9b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 21 Mar 2020 12:25:45 +0100
+Subject: PCI/switchtec: Fix init_completion race condition with poll_wait()
+
+From: Logan Gunthorpe <logang@deltatee.com>
+
+[ Upstream commit efbdc769601f4d50018bf7ca50fc9f7c67392ece ]
+
+The call to init_completion() in mrpc_queue_cmd() can theoretically
+race with the call to poll_wait() in switchtec_dev_poll().
+
+ poll() write()
+ switchtec_dev_poll() switchtec_dev_write()
+ poll_wait(&s->comp.wait); mrpc_queue_cmd()
+ init_completion(&s->comp)
+ init_waitqueue_head(&s->comp.wait)
+
+To my knowledge, no one has hit this bug.
+
+Fix this by using reinit_completion() instead of init_completion() in
+mrpc_queue_cmd().
+
+Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")
+
+Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Acked-by: Bjorn Helgaas <bhelgaas@google.com>
+Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/switch/switchtec.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
+index a823b4b8ef8a9..81dc7ac013817 100644
+--- a/drivers/pci/switch/switchtec.c
++++ b/drivers/pci/switch/switchtec.c
+@@ -175,7 +175,7 @@ static int mrpc_queue_cmd(struct switchtec_user *stuser)
+ kref_get(&stuser->kref);
+ stuser->read_len = sizeof(stuser->data);
+ stuser_set_state(stuser, MRPC_QUEUED);
+- init_completion(&stuser->comp);
++ reinit_completion(&stuser->comp);
+ list_add_tail(&stuser->list, &stdev->mrpc_queue);
+
+ mrpc_cmd_submit(stdev);
+--
+2.20.1
+
--- /dev/null
+From 0714f8c724a5deee493f015d0f2dccde6f6256ae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Feb 2020 17:46:39 +0800
+Subject: pstore/platform: fix potential mem leak if pstore_init_fs failed
+
+From: chenqiwu <chenqiwu@xiaomi.com>
+
+[ Upstream commit 8a57d6d4ddfa41c49014e20493152c41a38fcbf8 ]
+
+There is a potential mem leak when pstore_init_fs failed,
+since the pstore compression maybe unlikey to initialized
+successfully. We must clean up the allocation once this
+unlikey issue happens.
+
+Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
+Link: https://lore.kernel.org/r/1581068800-13817-1-git-send-email-qiwuchen55@gmail.com
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/pstore/platform.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
+index d896457e7c117..408277ee3cdb9 100644
+--- a/fs/pstore/platform.c
++++ b/fs/pstore/platform.c
+@@ -823,9 +823,9 @@ static int __init pstore_init(void)
+
+ ret = pstore_init_fs();
+ if (ret)
+- return ret;
++ free_buf_for_compression();
+
+- return 0;
++ return ret;
+ }
+ late_initcall(pstore_init);
+
+--
+2.20.1
+
--- /dev/null
+From 7179273c326a67649290c636ebb0de63da0d71db Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Mar 2020 10:15:15 +0800
+Subject: sched: Avoid scale real weight down to zero
+
+From: Michael Wang <yun.wang@linux.alibaba.com>
+
+[ Upstream commit 26cf52229efc87e2effa9d788f9b33c40fb3358a ]
+
+During our testing, we found a case that shares no longer
+working correctly, the cgroup topology is like:
+
+ /sys/fs/cgroup/cpu/A (shares=102400)
+ /sys/fs/cgroup/cpu/A/B (shares=2)
+ /sys/fs/cgroup/cpu/A/B/C (shares=1024)
+
+ /sys/fs/cgroup/cpu/D (shares=1024)
+ /sys/fs/cgroup/cpu/D/E (shares=1024)
+ /sys/fs/cgroup/cpu/D/E/F (shares=1024)
+
+The same benchmark is running in group C & F, no other tasks are
+running, the benchmark is capable to consumed all the CPUs.
+
+We suppose the group C will win more CPU resources since it could
+enjoy all the shares of group A, but it's F who wins much more.
+
+The reason is because we have group B with shares as 2, since
+A->cfs_rq.load.weight == B->se.load.weight == B->shares/nr_cpus,
+so A->cfs_rq.load.weight become very small.
+
+And in calc_group_shares() we calculate shares as:
+
+ load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg);
+ shares = (tg_shares * load) / tg_weight;
+
+Since the 'cfs_rq->load.weight' is too small, the load become 0
+after scale down, although 'tg_shares' is 102400, shares of the se
+which stand for group A on root cfs_rq become 2.
+
+While the se of D on root cfs_rq is far more bigger than 2, so it
+wins the battle.
+
+Thus when scale_load_down() scale real weight down to 0, it's no
+longer telling the real story, the caller will have the wrong
+information and the calculation will be buggy.
+
+This patch add check in scale_load_down(), so the real weight will
+be >= MIN_SHARES after scale, after applied the group C wins as
+expected.
+
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
+Link: https://lkml.kernel.org/r/38e8e212-59a1-64b2-b247-b6d0b52d8dc1@linux.alibaba.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sched/sched.h | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
+index 9ea647835fd6f..b056149c228ba 100644
+--- a/kernel/sched/sched.h
++++ b/kernel/sched/sched.h
+@@ -118,7 +118,13 @@ extern long calc_load_fold_active(struct rq *this_rq, long adjust);
+ #ifdef CONFIG_64BIT
+ # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT + SCHED_FIXEDPOINT_SHIFT)
+ # define scale_load(w) ((w) << SCHED_FIXEDPOINT_SHIFT)
+-# define scale_load_down(w) ((w) >> SCHED_FIXEDPOINT_SHIFT)
++# define scale_load_down(w) \
++({ \
++ unsigned long __w = (w); \
++ if (__w) \
++ __w = max(2UL, __w >> SCHED_FIXEDPOINT_SHIFT); \
++ __w; \
++})
+ #else
+ # define NICE_0_LOAD_SHIFT (SCHED_FIXEDPOINT_SHIFT)
+ # define scale_load(w) (w)
+--
+2.20.1
+
--- /dev/null
+From 27be83cfd80887eeaf738a66211d4f5ddb2c912a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 19 Mar 2020 11:39:20 +0800
+Subject: sched/fair: Fix condition of avg_load calculation
+
+From: Tao Zhou <ouwen210@hotmail.com>
+
+[ Upstream commit 6c8116c914b65be5e4d6f66d69c8142eb0648c22 ]
+
+In update_sg_wakeup_stats(), the comment says:
+
+Computing avg_load makes sense only when group is fully
+busy or overloaded.
+
+But, the code below this comment does not check like this.
+
+From reading the code about avg_load in other functions, I
+confirm that avg_load should be calculated in fully busy or
+overloaded case. The comment is correct and the checking
+condition is wrong. So, change that condition.
+
+Fixes: 57abff067a08 ("sched/fair: Rework find_idlest_group()")
+Signed-off-by: Tao Zhou <ouwen210@hotmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
+Acked-by: Mel Gorman <mgorman@suse.de>
+Link: https://lkml.kernel.org/r/Message-ID:
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sched/fair.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
+index c1217bfe5e819..7f895d5139948 100644
+--- a/kernel/sched/fair.c
++++ b/kernel/sched/fair.c
+@@ -8345,7 +8345,8 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd,
+ * Computing avg_load makes sense only when group is fully busy or
+ * overloaded
+ */
+- if (sgs->group_type < group_fully_busy)
++ if (sgs->group_type == group_fully_busy ||
++ sgs->group_type == group_overloaded)
+ sgs->avg_load = (sgs->group_load * SCHED_CAPACITY_SCALE) /
+ sgs->group_capacity;
+ }
+--
+2.20.1
+
--- /dev/null
+From 7f12bdfa9c7689c54bf1870fc1179399b0012253 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 23 Jan 2020 19:08:49 +0100
+Subject: sched/vtime: Prevent unstable evaluation of WARN(vtime->state)
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+[ Upstream commit f1dfdab694eb3838ac26f4b73695929c07d92a33 ]
+
+As the vtime is sampled under loose seqcount protection by kcpustat, the
+vtime fields may change as the code flows. Where logic dictates a field
+has a static value, use a READ_ONCE.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Fixes: 74722bb223d0 ("sched/vtime: Bring up complete kcpustat accessor")
+Link: https://lkml.kernel.org/r/20200123180849.28486-1-frederic@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/sched/cputime.c | 41 ++++++++++++++++++++++-------------------
+ 1 file changed, 22 insertions(+), 19 deletions(-)
+
+diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
+index cff3e656566d6..dac9104d126f7 100644
+--- a/kernel/sched/cputime.c
++++ b/kernel/sched/cputime.c
+@@ -909,8 +909,10 @@ void task_cputime(struct task_struct *t, u64 *utime, u64 *stime)
+ } while (read_seqcount_retry(&vtime->seqcount, seq));
+ }
+
+-static int vtime_state_check(struct vtime *vtime, int cpu)
++static int vtime_state_fetch(struct vtime *vtime, int cpu)
+ {
++ int state = READ_ONCE(vtime->state);
++
+ /*
+ * We raced against a context switch, fetch the
+ * kcpustat task again.
+@@ -927,10 +929,10 @@ static int vtime_state_check(struct vtime *vtime, int cpu)
+ *
+ * Case 1) is ok but 2) is not. So wait for a safe VTIME state.
+ */
+- if (vtime->state == VTIME_INACTIVE)
++ if (state == VTIME_INACTIVE)
+ return -EAGAIN;
+
+- return 0;
++ return state;
+ }
+
+ static u64 kcpustat_user_vtime(struct vtime *vtime)
+@@ -949,14 +951,15 @@ static int kcpustat_field_vtime(u64 *cpustat,
+ {
+ struct vtime *vtime = &tsk->vtime;
+ unsigned int seq;
+- int err;
+
+ do {
++ int state;
++
+ seq = read_seqcount_begin(&vtime->seqcount);
+
+- err = vtime_state_check(vtime, cpu);
+- if (err < 0)
+- return err;
++ state = vtime_state_fetch(vtime, cpu);
++ if (state < 0)
++ return state;
+
+ *val = cpustat[usage];
+
+@@ -969,7 +972,7 @@ static int kcpustat_field_vtime(u64 *cpustat,
+ */
+ switch (usage) {
+ case CPUTIME_SYSTEM:
+- if (vtime->state == VTIME_SYS)
++ if (state == VTIME_SYS)
+ *val += vtime->stime + vtime_delta(vtime);
+ break;
+ case CPUTIME_USER:
+@@ -981,11 +984,11 @@ static int kcpustat_field_vtime(u64 *cpustat,
+ *val += kcpustat_user_vtime(vtime);
+ break;
+ case CPUTIME_GUEST:
+- if (vtime->state == VTIME_GUEST && task_nice(tsk) <= 0)
++ if (state == VTIME_GUEST && task_nice(tsk) <= 0)
+ *val += vtime->gtime + vtime_delta(vtime);
+ break;
+ case CPUTIME_GUEST_NICE:
+- if (vtime->state == VTIME_GUEST && task_nice(tsk) > 0)
++ if (state == VTIME_GUEST && task_nice(tsk) > 0)
+ *val += vtime->gtime + vtime_delta(vtime);
+ break;
+ default:
+@@ -1036,23 +1039,23 @@ static int kcpustat_cpu_fetch_vtime(struct kernel_cpustat *dst,
+ {
+ struct vtime *vtime = &tsk->vtime;
+ unsigned int seq;
+- int err;
+
+ do {
+ u64 *cpustat;
+ u64 delta;
++ int state;
+
+ seq = read_seqcount_begin(&vtime->seqcount);
+
+- err = vtime_state_check(vtime, cpu);
+- if (err < 0)
+- return err;
++ state = vtime_state_fetch(vtime, cpu);
++ if (state < 0)
++ return state;
+
+ *dst = *src;
+ cpustat = dst->cpustat;
+
+ /* Task is sleeping, dead or idle, nothing to add */
+- if (vtime->state < VTIME_SYS)
++ if (state < VTIME_SYS)
+ continue;
+
+ delta = vtime_delta(vtime);
+@@ -1061,15 +1064,15 @@ static int kcpustat_cpu_fetch_vtime(struct kernel_cpustat *dst,
+ * Task runs either in user (including guest) or kernel space,
+ * add pending nohz time to the right place.
+ */
+- if (vtime->state == VTIME_SYS) {
++ if (state == VTIME_SYS) {
+ cpustat[CPUTIME_SYSTEM] += vtime->stime + delta;
+- } else if (vtime->state == VTIME_USER) {
++ } else if (state == VTIME_USER) {
+ if (task_nice(tsk) > 0)
+ cpustat[CPUTIME_NICE] += vtime->utime + delta;
+ else
+ cpustat[CPUTIME_USER] += vtime->utime + delta;
+ } else {
+- WARN_ON_ONCE(vtime->state != VTIME_GUEST);
++ WARN_ON_ONCE(state != VTIME_GUEST);
+ if (task_nice(tsk) > 0) {
+ cpustat[CPUTIME_GUEST_NICE] += vtime->gtime + delta;
+ cpustat[CPUTIME_NICE] += vtime->gtime + delta;
+@@ -1080,7 +1083,7 @@ static int kcpustat_cpu_fetch_vtime(struct kernel_cpustat *dst,
+ }
+ } while (read_seqcount_retry(&vtime->seqcount, seq));
+
+- return err;
++ return 0;
+ }
+
+ void kcpustat_cpu_fetch(struct kernel_cpustat *dst, int cpu)
+--
+2.20.1
+
--- /dev/null
+From 206bef3c074b92ed30acd8b5511ce835391f153c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Mar 2020 15:35:51 -0700
+Subject: selftests/x86/ptrace_syscall_32: Fix no-vDSO segfault
+
+From: Andy Lutomirski <luto@kernel.org>
+
+[ Upstream commit 630b99ab60aa972052a4202a1ff96c7e45eb0054 ]
+
+If AT_SYSINFO is not present, don't try to call a NULL pointer.
+
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: https://lkml.kernel.org/r/faaf688265a7e1a5b944d6f8bc0f6368158306d3.1584052409.git.luto@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/x86/ptrace_syscall.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/tools/testing/selftests/x86/ptrace_syscall.c b/tools/testing/selftests/x86/ptrace_syscall.c
+index 6f22238f32173..12aaa063196e7 100644
+--- a/tools/testing/selftests/x86/ptrace_syscall.c
++++ b/tools/testing/selftests/x86/ptrace_syscall.c
+@@ -414,8 +414,12 @@ int main()
+
+ #if defined(__i386__) && (!defined(__GLIBC__) || __GLIBC__ > 2 || __GLIBC_MINOR__ >= 16)
+ vsyscall32 = (void *)getauxval(AT_SYSINFO);
+- printf("[RUN]\tCheck AT_SYSINFO return regs\n");
+- test_sys32_regs(do_full_vsyscall32);
++ if (vsyscall32) {
++ printf("[RUN]\tCheck AT_SYSINFO return regs\n");
++ test_sys32_regs(do_full_vsyscall32);
++ } else {
++ printf("[SKIP]\tAT_SYSINFO is not available\n");
++ }
+ #endif
+
+ test_ptrace_syscall_restart();
+--
+2.20.1
+
--- /dev/null
+media-rc-add-keymap-for-videostrong-kii-pro.patch
+cpufreq-imx6q-fixes-unwanted-cpu-overclocking-on-i.m.patch
+edac-mc-report-unknown-memory-on-too-many-dimm-label.patch
+usb-ucsi-ccg-disable-runtime-pm-during-fw-flashing.patch
+staging-wilc1000-avoid-double-unlocking-of-wilc-hif_.patch
+media-vimc-streamer-fix-memory-leak-in-vimc-subdevs-.patch
+media-hantro-fix-extra-mv-mc-sync-space-calculation.patch
+media-staging-rkisp1-use-consistent-bus_info-string-.patch
+media-staging-rkisp1-isp-do-not-set-invalid-mbus-cod.patch
+media-venus-hfi_parser-ignore-hevc-encoding-for-v1.patch
+firmware-arm_sdei-fix-double-lock-on-hibernate-with-.patch
+media-arm64-dts-amlogic-add-rc-videostrong-kii-pro-k.patch
+usb-phy-tegra-include-proper-gpio-consumer-header-to.patch
+arm64-mm-hold-memory-hotplug-lock-while-walking-for-.patch
+sched-vtime-prevent-unstable-evaluation-of-warn-vtim.patch
+iio-imu-st_lsm6dsx-check-return-value-from-st_lsm6ds.patch
+null_blk-fix-the-null_add_dev-error-path.patch
+blk-mq-fix-a-recently-introduced-regression-in-blk_m.patch
+null_blk-handle-null_add_dev-failures-properly.patch
+null_blk-suppress-an-ubsan-complaint-triggered-when-.patch
+null_blk-fix-spurious-io-errors-after-failed-past-wp.patch
+media-imx-imx7_mipi_csis-power-off-the-source-when-s.patch
+media-imx-imx7-media-csi-fix-video-field-handling.patch
+xhci-bail-out-early-if-driver-can-t-accress-host-in-.patch
+acpi-ec-do-not-clear-boot_ec_is_ecdt-in-acpi_ec_add.patch
+clocksource-drivers-timer-microchip-pit64b-fix-rate-.patch
+x86-don-t-let-pgprot_modify-change-the-page-encrypti.patch
+dma-mapping-fix-dma_pgprot-for-unencrypted-coherent-.patch
+block-keep-bdi-io_pages-in-sync-with-max_sectors_kb-.patch
+debugfs-check-module-state-before-warning-in-full-op.patch
+spi-spi-fsl-dspi-avoid-null-pointer-in-dspi_slave_ab.patch
+irqchip-versatile-fpga-handle-chained-irqs-properly.patch
+time-sched_clock-expire-timer-in-hardirq-context.patch
+irqchip-gic-v4.1-skip-absent-cpus-while-iterating-ov.patch
+media-allegro-fix-type-of-gop_length-in-channel_crea.patch
+sched-avoid-scale-real-weight-down-to-zero.patch
+sched-fair-fix-condition-of-avg_load-calculation.patch
+selftests-x86-ptrace_syscall_32-fix-no-vdso-segfault.patch
+pci-switchtec-fix-init_completion-race-condition-wit.patch
+block-bfq-move-forward-the-getting-of-an-extra-ref-i.patch
+media-i2c-video-i2c-fix-build-errors-due-to-imply-hw.patch
+libata-remove-extra-scsi_host_put-in-ata_scsi_add_ho.patch
+pstore-platform-fix-potential-mem-leak-if-pstore_ini.patch
+gfs2-do-log_flush-in-gfs2_ail_empty_gl-even-if-ail-l.patch
+gfs2-don-t-demote-a-glock-until-its-revokes-are-writ.patch
+cpufreq-imx6q-fix-error-handling.patch
+x86-boot-use-unsigned-comparison-for-addresses.patch
+efi-x86-ignore-the-memory-attributes-table-on-i386.patch
+genirq-irqdomain-check-pointer-in-irq_domain_alloc_i.patch
+block-fix-use-after-free-issue-accessing-struct-io_c.patch
+block-zoned-fix-integer-overflow-with-blkresetzone-e.patch
+media-mtk-vpu-avoid-unaligned-access-to-dtcm-buffer.patch
+media-i2c-ov5695-fix-power-on-and-off-sequences.patch
+usb-dwc3-core-add-support-for-disabling-ss-instances.patch
+irqchip-gic-v4-provide-irq_retrigger-to-avoid-circul.patch
+md-check-arrays-is-suspended-in-mddev_detach-before-.patch
+firmware-fix-a-double-abort-case-with-fw_load_sysfs_.patch
+spi-spi-fsl-dspi-replace-interruptible-wait-queue-wi.patch
+locking-lockdep-avoid-recursion-in-lockdep_count_-fo.patch
+staging-mt7621-pci-avoid-to-poweroff-the-phy-for-slo.patch
+block-bfq-fix-use-after-free-in-bfq_idle_slice_timer.patch
+btrfs-qgroup-ensure-qgroup_rescan_running-is-only-se.patch
+btrfs-remove-a-bug_on-from-merge_reloc_roots.patch
+btrfs-restart-relocate_tree_blocks-properly.patch
+btrfs-track-reloc-roots-based-on-their-commit-root-b.patch
--- /dev/null
+From 26b7bb2fcea5c764e6cb296028a147e048fc71b8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Mar 2020 02:15:58 +0200
+Subject: spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA
+ mode
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 3d6224e63be39ff26cf416492cb3923cd3d07dd0 ]
+
+The driver does not create the dspi->dma structure unless operating in
+DSPI_DMA_MODE, so it makes sense to check for that.
+
+Fixes: f4b323905d8b ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver")
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Michael Walle <michael@walle.cc>
+Link: https://lore.kernel.org/r/20200318001603.9650-8-olteanv@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-fsl-dspi.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
+index 6ec2dcb8c57a6..2ce65edf16b66 100644
+--- a/drivers/spi/spi-fsl-dspi.c
++++ b/drivers/spi/spi-fsl-dspi.c
+@@ -1021,8 +1021,10 @@ static int dspi_slave_abort(struct spi_master *master)
+ * Terminate all pending DMA transactions for the SPI working
+ * in SLAVE mode.
+ */
+- dmaengine_terminate_sync(dspi->dma->chan_rx);
+- dmaengine_terminate_sync(dspi->dma->chan_tx);
++ if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
++ dmaengine_terminate_sync(dspi->dma->chan_rx);
++ dmaengine_terminate_sync(dspi->dma->chan_tx);
++ }
+
+ /* Clear the internal DSPI RX and TX FIFO buffers */
+ regmap_update_bits(dspi->regmap, SPI_MCR,
+--
+2.20.1
+
--- /dev/null
+From add0158ea249073704a1bc4badbafff8f47e2dcf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Mar 2020 02:15:57 +0200
+Subject: spi: spi-fsl-dspi: Replace interruptible wait queue with a simple
+ completion
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit 4f5ee75ea1718a09149460b3df993f389a67b56a ]
+
+Currently the driver puts the process in interruptible sleep waiting for
+the interrupt train to finish transfer to/from the tx_buf and rx_buf.
+
+But exiting the process with ctrl-c may make the kernel panic: the
+wait_event_interruptible call will return -ERESTARTSYS, which a proper
+driver implementation is perhaps supposed to handle, but nonetheless
+this one doesn't, and aborts the transfer altogether.
+
+Actually when the task is interrupted, there is still a high chance that
+the dspi_interrupt is still triggering. And if dspi_transfer_one_message
+returns execution all the way to the spi_device driver, that can free
+the spi_message and spi_transfer structures, leaving the interrupts to
+access a freed tx_buf and rx_buf.
+
+hexdump -C /dev/mtd0
+00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff
+|.uhu............|
+00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
+|................|
+*
+^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed!
+[ 38.503097] spi_master spi2: failed to transfer one message from queue
+[ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377
+[ 38.517676] Mem abort info:
+[ 38.520474] ESR = 0x96000045
+[ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits
+[ 38.528861] SET = 0, FnV = 0
+[ 38.531921] EA = 0, S1PTW = 0
+[ 38.535067] Data abort info:
+[ 38.537952] ISV = 0, ISS = 0x00000045
+[ 38.541797] CM = 0, WnR = 1
+[ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000
+[ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000
+[ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
+[ 38.565819] Modules linked in:
+[ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
+[ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
+[ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
+[ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110
+[ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90
+[ 38.601203] sp : ffff800010003d90
+[ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000
+[ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400
+[ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
+[ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
+[ 38.625841] x21: 000000000000146e x20: ffff8000120c3000
+[ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
+[ 38.636498] x17: 0000000000000000 x16: 0000000000000000
+[ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720
+[ 38.647155] x13: 0720072007200765 x12: 0775076507750771
+[ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040
+[ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
+[ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
+[ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
+[ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
+[ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
+[ 38.684454] Call trace:
+[ 38.686905] ktime_get_real_ts64+0x3c/0x110
+[ 38.691100] spi_take_timestamp_pre+0x40/0x90
+[ 38.695470] dspi_fifo_write+0x58/0x2c0
+[ 38.699315] dspi_interrupt+0xbc/0xd0
+[ 38.702987] __handle_irq_event_percpu+0x78/0x2c0
+[ 38.707706] handle_irq_event_percpu+0x3c/0x90
+[ 38.712161] handle_irq_event+0x4c/0xd0
+[ 38.716008] handle_fasteoi_irq+0xbc/0x170
+[ 38.720115] generic_handle_irq+0x2c/0x40
+[ 38.724135] __handle_domain_irq+0x68/0xc0
+[ 38.728243] gic_handle_irq+0xc8/0x160
+[ 38.732000] el1_irq+0xb8/0x180
+[ 38.735149] spi_nor_spimem_read_data+0xe0/0x140
+[ 38.739779] spi_nor_read+0xc4/0x120
+[ 38.743364] mtd_read_oob+0xa8/0xc0
+[ 38.746860] mtd_read+0x4c/0x80
+[ 38.750007] mtdchar_read+0x108/0x2a0
+[ 38.753679] __vfs_read+0x20/0x50
+[ 38.757002] vfs_read+0xa4/0x190
+[ 38.760237] ksys_read+0x6c/0xf0
+[ 38.763471] __arm64_sys_read+0x20/0x30
+[ 38.767319] el0_svc_common.constprop.3+0x90/0x160
+[ 38.772125] do_el0_svc+0x28/0x90
+[ 38.775449] el0_sync_handler+0x118/0x190
+[ 38.779468] el0_sync+0x140/0x180
+[ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
+[ 38.788910] ---[ end trace 55da560db4d6bef7 ]---
+[ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt
+[ 38.799914] SMP: stopping secondary CPUs
+[ 38.803849] Kernel Offset: disabled
+[ 38.807344] CPU features: 0x10002,20006008
+[ 38.811451] Memory Limit: none
+[ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
+
+So it is clear that the "interruptible" part isn't handled correctly.
+When the process receives a signal, one could either attempt a clean
+abort (which appears to be difficult with this hardware) or just keep
+restarting the sleep until the wait queue really completes. But checking
+in a loop for -ERESTARTSYS is a bit too complicated for this driver, so
+just make the sleep uninterruptible, to avoid all that nonsense.
+
+The wait queue was actually restructured as a completion, after polling
+other drivers for the most "popular" approach.
+
+Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
+Reported-by: Michael Walle <michael@walle.cc>
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Michael Walle <michael@walle.cc>
+Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-fsl-dspi.c | 19 ++++++-------------
+ 1 file changed, 6 insertions(+), 13 deletions(-)
+
+diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
+index 2ce65edf16b66..1305030379e82 100644
+--- a/drivers/spi/spi-fsl-dspi.c
++++ b/drivers/spi/spi-fsl-dspi.c
+@@ -196,8 +196,7 @@ struct fsl_dspi {
+ u8 bytes_per_word;
+ const struct fsl_dspi_devtype_data *devtype_data;
+
+- wait_queue_head_t waitq;
+- u32 waitflags;
++ struct completion xfer_done;
+
+ struct fsl_dspi_dma *dma;
+ };
+@@ -714,10 +713,8 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
+ if (!(spi_sr & SPI_SR_EOQF))
+ return IRQ_NONE;
+
+- if (dspi_rxtx(dspi) == 0) {
+- dspi->waitflags = 1;
+- wake_up_interruptible(&dspi->waitq);
+- }
++ if (dspi_rxtx(dspi) == 0)
++ complete(&dspi->xfer_done);
+
+ return IRQ_HANDLED;
+ }
+@@ -815,13 +812,9 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
+ status = dspi_poll(dspi);
+ } while (status == -EINPROGRESS);
+ } else if (trans_mode != DSPI_DMA_MODE) {
+- status = wait_event_interruptible(dspi->waitq,
+- dspi->waitflags);
+- dspi->waitflags = 0;
++ wait_for_completion(&dspi->xfer_done);
++ reinit_completion(&dspi->xfer_done);
+ }
+- if (status)
+- dev_err(&dspi->pdev->dev,
+- "Waiting for transfer to complete failed!\n");
+
+ spi_transfer_delay_exec(transfer);
+ }
+@@ -1161,7 +1154,7 @@ static int dspi_probe(struct platform_device *pdev)
+ goto out_clk_put;
+ }
+
+- init_waitqueue_head(&dspi->waitq);
++ init_completion(&dspi->xfer_done);
+
+ poll_mode:
+
+--
+2.20.1
+
--- /dev/null
+From ec6be285a08459ccdcdd1287bbf5a687a7dffc19 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Mar 2020 16:38:37 +0100
+Subject: staging: mt7621-pci: avoid to poweroff the phy for slot one
+
+From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+[ Upstream commit 5737cfe87a9c242ad0f60b34b5ac1688770a9236 ]
+
+Phy for slot 0 and 1 is shared and handled properly in slot 0.
+If there is only one port in use,(slot 0) we shall not call the
+'phy_power_off' function with an invalid slot because kernel
+will crash with an unaligned access fault like the following:
+
+mt7621-pci 1e140000.pcie: Error applying setting, reverse things back
+mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1)
+mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0)
+mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
+mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
+mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
+Unhandled kernel unaligned access[#1]:
+CPU: 3 PID: 111 Comm: kworker/3:2 Not tainted 5.6.0-rc3-00347-g825c6f470c62-dirty #9
+Workqueue: events deferred_probe_work_func
+$ 0 : 00000000 00000001 5f60d043 8fe1ba80
+$ 4 : 0000010d 01eb9000 00000000 00000000
+$ 8 : 294b4c00 80940000 00000008 000000ce
+$12 : 2e303030 00000000 00000000 65696370
+$16 : ffffffed 0000010d 8e373cd0 8214c1e0
+$20 : 00000000 82144c80 82144680 8214c250
+$24 : 00000018 803ef8f4
+$28 : 8e372000 8e373c60 8214c080 803940e8
+Hi : 00000125
+Lo : 122f2000
+epc : 807b3328 mutex_lock+0x8/0x44
+ra : 803940e8 phy_power_off+0x28/0xb0
+Status: 1100fc03 KERNEL EXL IE
+Cause : 00800010 (ExcCode 04)
+BadVA : 0000010d
+PrId : 0001992f (MIPS 1004Kc)
+Modules linked in:
+Process kworker/3:2 (pid: 111, threadinfo=(ptrval), task=(ptrval), tls=00000000)
+Stack : 8e373cd0 803fe4f4 8e372000 8e373c90 8214c080 804fde1c 8e373c98 808d62f4
+ 8e373c78 00000000 8214c254 804fe648 1e160000 804f27b8 00000001 808d62f4
+ 00000000 00000001 8214c228 808d62f4 80930000 809a0000 8fd47e10 808d63d4
+ 808d62d4 8fd47e10 808d0000 808d0000 8e373cd0 8e373cd0 809e2a74 809db510
+ 809db510 00000006 00000001 00000000 00000000 00000000 01000000 1e1440ff
+ ...
+Call Trace:
+[<807b3328>] mutex_lock+0x8/0x44
+[<803940e8>] phy_power_off+0x28/0xb0
+[<804fe648>] mt7621_pci_probe+0xc20/0xd18
+[<80402ab8>] platform_drv_probe+0x40/0x94
+[<80400a74>] really_probe+0x104/0x364
+[<803feb74>] bus_for_each_drv+0x84/0xdc
+[<80400924>] __device_attach+0xdc/0x120
+[<803ffb5c>] bus_probe_device+0xa0/0xbc
+[<80400124>] deferred_probe_work_func+0x7c/0xbc
+[<800420e8>] process_one_work+0x230/0x450
+[<80042638>] worker_thread+0x330/0x5fc
+[<80048eb0>] kthread+0x12c/0x134
+[<80007438>] ret_from_kernel_thread+0x14/0x1c
+Code: 24050002 27bdfff8 8f830000 <c0850000> 14a00005 00000000 00600825 e0810000 1020fffa
+
+Fixes: bf516f413f4e ("staging: mt7621-pci: use only two phys from device tree")
+Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
+Link: https://lore.kernel.org/r/20200320153837.20415-1-sergio.paracuellos@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/mt7621-pci/pci-mt7621.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c b/drivers/staging/mt7621-pci/pci-mt7621.c
+index 3633c924848ec..a1dafec0890a9 100644
+--- a/drivers/staging/mt7621-pci/pci-mt7621.c
++++ b/drivers/staging/mt7621-pci/pci-mt7621.c
+@@ -485,7 +485,8 @@ static void mt7621_pcie_init_ports(struct mt7621_pcie *pcie)
+ if (!mt7621_pcie_port_is_linkup(port)) {
+ dev_err(dev, "pcie%d no card, disable it (RST & CLK)\n",
+ slot);
+- phy_power_off(port->phy);
++ if (slot != 1)
++ phy_power_off(port->phy);
+ mt7621_control_assert(port);
+ mt7621_pcie_port_clk_disable(port);
+ port->enabled = false;
+--
+2.20.1
+
--- /dev/null
+From 7d98a9189756acf93b6d7b1f5673f119dc632baf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 11:30:20 +0000
+Subject: staging: wilc1000: avoid double unlocking of 'wilc->hif_cs' mutex
+
+From: Ajay Singh <ajay.kathat@microchip.com>
+
+[ Upstream commit 6c411581caef6e3b2c286871641018364c6db50a ]
+
+Possible double unlocking of 'wilc->hif_cs' mutex was identified by
+smatch [1]. Removed the extra call to release_bus() in
+wilc_wlan_handle_txq() which was missed in earlier commit fdc2ac1aafc6
+("staging: wilc1000: support suspend/resume functionality").
+
+[1]. https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/NOEVW7C3GV74EWXJO3XX6VT2NKVB2HMT/
+
+Reported-by: kbuild test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
+Link: https://lore.kernel.org/r/20200221170120.15739-1-ajay.kathat@microchip.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/wilc1000/wlan.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/staging/wilc1000/wlan.c b/drivers/staging/wilc1000/wlan.c
+index 601e4d1345d24..05b8adfe001da 100644
+--- a/drivers/staging/wilc1000/wlan.c
++++ b/drivers/staging/wilc1000/wlan.c
+@@ -572,7 +572,6 @@ int wilc_wlan_handle_txq(struct wilc *wilc, u32 *txq_count)
+ entries = ((reg >> 3) & 0x3f);
+ break;
+ }
+- release_bus(wilc, WILC_BUS_RELEASE_ALLOW_SLEEP);
+ } while (--timeout);
+ if (timeout <= 0) {
+ ret = func->hif_write_reg(wilc, WILC_HOST_VMM_CTL, 0x0);
+--
+2.20.1
+
--- /dev/null
+From c41cf82975a37c0666c5adc0868d5933b4821422 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Mar 2020 18:15:29 +0000
+Subject: time/sched_clock: Expire timer in hardirq context
+
+From: Ahmed S. Darwish <a.darwish@linutronix.de>
+
+[ Upstream commit 2c8bd58812ee3dbf0d78b566822f7eacd34bdd7b ]
+
+To minimize latency, PREEMPT_RT kernels expires hrtimers in preemptible
+softirq context by default. This can be overriden by marking the timer's
+expiry with HRTIMER_MODE_HARD.
+
+sched_clock_timer is missing this annotation: if its callback is preempted
+and the duration of the preemption exceeds the wrap around time of the
+underlying clocksource, sched clock will get out of sync.
+
+Mark the sched_clock_timer for expiry in hard interrupt context.
+
+Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lkml.kernel.org/r/20200309181529.26558-1-a.darwish@linutronix.de
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/time/sched_clock.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
+index e4332e3e2d569..fa3f800d7d763 100644
+--- a/kernel/time/sched_clock.c
++++ b/kernel/time/sched_clock.c
+@@ -208,7 +208,8 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned long rate)
+
+ if (sched_clock_timer.function != NULL) {
+ /* update timeout for clock wrap */
+- hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
++ hrtimer_start(&sched_clock_timer, cd.wrap_kt,
++ HRTIMER_MODE_REL_HARD);
+ }
+
+ r = rate;
+@@ -254,9 +255,9 @@ void __init generic_sched_clock_init(void)
+ * Start the timer to keep sched_clock() properly updated and
+ * sets the initial epoch.
+ */
+- hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
++ hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
+ sched_clock_timer.function = sched_clock_poll;
+- hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
++ hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL_HARD);
+ }
+
+ /*
+@@ -293,7 +294,7 @@ void sched_clock_resume(void)
+ struct clock_read_data *rd = &cd.read_data[0];
+
+ rd->epoch_cyc = cd.actual_read_sched_clock();
+- hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
++ hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL_HARD);
+ rd->read_sched_clock = cd.actual_read_sched_clock;
+ }
+
+--
+2.20.1
+
--- /dev/null
+From edb33020afcfa3675e5a0484a03edb77c9d28b53 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 21 Feb 2020 10:15:31 +0100
+Subject: usb: dwc3: core: add support for disabling SS instances in park mode
+
+From: Neil Armstrong <narmstrong@baylibre.com>
+
+[ Upstream commit 7ba6b09fda5e0cb741ee56f3264665e0edc64822 ]
+
+In certain circumstances, the XHCI SuperSpeed instance in park mode
+can fail to recover, thus on Amlogic G12A/G12B/SM1 SoCs when there is high
+load on the single XHCI SuperSpeed instance, the controller can crash like:
+ xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
+ xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
+ xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
+ xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
+ hub 2-1.1:1.0: hub_ext_port_status failed (err = -22)
+ xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
+ usb 2-1.1-port1: cannot reset (err = -22)
+
+Setting the PARKMODE_DISABLE_SS bit in the DWC3_USB3_GUCTL1 mitigates
+the issue. The bit is described as :
+"When this bit is set to '1' all SS bus instances in park mode are disabled"
+
+Synopsys explains:
+The GUCTL1.PARKMODE_DISABLE_SS is only available in
+dwc_usb3 controller running in host mode.
+This should not be set for other IPs.
+This can be disabled by default based on IP, but I recommend to have a
+property to enable this feature for devices that need this.
+
+CC: Dongjin Kim <tobetter@gmail.com>
+Cc: Jianxin Pan <jianxin.pan@amlogic.com>
+Cc: Thinh Nguyen <thinhn@synopsys.com>
+Cc: Jun Li <lijun.kernel@gmail.com>
+Reported-by: Tim <elatllat@gmail.com>
+Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/dwc3/core.c | 5 +++++
+ drivers/usb/dwc3/core.h | 4 ++++
+ 2 files changed, 9 insertions(+)
+
+diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
+index 1d85c42b9c674..43bd5b1ea9e2c 100644
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -1029,6 +1029,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
+ if (dwc->dis_tx_ipgap_linecheck_quirk)
+ reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
++ if (dwc->parkmode_disable_ss_quirk)
++ reg |= DWC3_GUCTL1_PARKMODE_DISABLE_SS;
++
+ dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
+ }
+
+@@ -1342,6 +1345,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
+ "snps,dis-del-phy-power-chg-quirk");
+ dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
+ "snps,dis-tx-ipgap-linecheck-quirk");
++ dwc->parkmode_disable_ss_quirk = device_property_read_bool(dev,
++ "snps,parkmode-disable-ss-quirk");
+
+ dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
+ "snps,tx_de_emphasis_quirk");
+diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
+index 77c4a9abe3652..3ecc69c5b150f 100644
+--- a/drivers/usb/dwc3/core.h
++++ b/drivers/usb/dwc3/core.h
+@@ -249,6 +249,7 @@
+ #define DWC3_GUCTL_HSTINAUTORETRY BIT(14)
+
+ /* Global User Control 1 Register */
++#define DWC3_GUCTL1_PARKMODE_DISABLE_SS BIT(17)
+ #define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
+ #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
+
+@@ -1024,6 +1025,8 @@ struct dwc3_scratchpad_array {
+ * change quirk.
+ * @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
++ * @parkmode_disable_ss_quirk: set if we need to disable all SuperSpeed
++ * instances in park mode.
+ * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
+ * @tx_de_emphasis: Tx de-emphasis value
+ * 0 - -6dB de-emphasis
+@@ -1215,6 +1218,7 @@ struct dwc3 {
+ unsigned dis_u2_freeclk_exists_quirk:1;
+ unsigned dis_del_phy_power_chg_quirk:1;
+ unsigned dis_tx_ipgap_linecheck_quirk:1;
++ unsigned parkmode_disable_ss_quirk:1;
+
+ unsigned tx_de_emphasis_quirk:1;
+ unsigned tx_de_emphasis:2;
+--
+2.20.1
+
--- /dev/null
+From 1be3d8561d3bf209e0e4f258ea5b419465c50399 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Mar 2020 12:29:20 +0100
+Subject: usb: phy: tegra: Include proper GPIO consumer header to fix compile
+ testing
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Krzysztof Kozlowski <krzk@kernel.org>
+
+[ Upstream commit 9cb9322a26ae84424c3e16e58617b3d8962fdbbb ]
+
+The driver uses only GPIO Descriptor Consumer Interface so include
+proper header. This fixes compile test failures (e.g. on i386):
+
+ drivers/usb/phy/phy-tegra-usb.c: In function ‘ulpi_phy_power_on’:
+ drivers/usb/phy/phy-tegra-usb.c:695:2: error:
+ implicit declaration of function ‘gpiod_set_value_cansleep’ [-Werror=implicit-function-declaration]
+ drivers/usb/phy/phy-tegra-usb.c: In function ‘tegra_usb_phy_probe’:
+ drivers/usb/phy/phy-tegra-usb.c:1167:11: error:
+ implicit declaration of function ‘devm_gpiod_get_from_of_node’ [-Werror=implicit-function-declaration]
+
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
+Link: https://lore.kernel.org/r/1583234960-24909-1-git-send-email-krzk@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/phy/phy-tegra-usb.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
+index 6153cc35aba0d..cffe2aced4884 100644
+--- a/drivers/usb/phy/phy-tegra-usb.c
++++ b/drivers/usb/phy/phy-tegra-usb.c
+@@ -12,12 +12,11 @@
+ #include <linux/delay.h>
+ #include <linux/err.h>
+ #include <linux/export.h>
+-#include <linux/gpio.h>
++#include <linux/gpio/consumer.h>
+ #include <linux/iopoll.h>
+ #include <linux/module.h>
+ #include <linux/of.h>
+ #include <linux/of_device.h>
+-#include <linux/of_gpio.h>
+ #include <linux/platform_device.h>
+ #include <linux/resource.h>
+ #include <linux/slab.h>
+--
+2.20.1
+
--- /dev/null
+From 31de82fb7807085ae24b00116bd30328e0bd3627 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 17 Feb 2020 17:49:12 +0300
+Subject: usb: ucsi: ccg: disable runtime pm during fw flashing
+
+From: Ajay Gupta <ajayg@nvidia.com>
+
+[ Upstream commit 57a5e5f936be583d2c6cef3661c169e3ea4bf922 ]
+
+Ucsi ppm is unregistered during fw flashing so disable
+runtime pm also and reenable after fw flashing is completed
+and ppm is re-registered.
+
+Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
+Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20200217144913.55330-3-heikki.krogerus@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/typec/ucsi/ucsi_ccg.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c b/drivers/usb/typec/ucsi/ucsi_ccg.c
+index a5b8530490dba..2658cda5da116 100644
+--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
++++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
+@@ -1219,6 +1219,7 @@ static int ccg_restart(struct ucsi_ccg *uc)
+ return status;
+ }
+
++ pm_runtime_enable(uc->dev);
+ return 0;
+ }
+
+@@ -1234,6 +1235,7 @@ static void ccg_update_firmware(struct work_struct *work)
+
+ if (flash_mode != FLASH_NOT_NEEDED) {
+ ucsi_unregister(uc->ucsi);
++ pm_runtime_disable(uc->dev);
+ free_irq(uc->irq, uc);
+
+ ccg_fw_update(uc, flash_mode);
+--
+2.20.1
+
--- /dev/null
+From 37a8a0f6dc39c6dbc214e64c4c91e65c2fd567b1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 8 Mar 2020 09:08:44 +0100
+Subject: x86/boot: Use unsigned comparison for addresses
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+[ Upstream commit 81a34892c2c7c809f9c4e22c5ac936ae673fb9a2 ]
+
+The load address is compared with LOAD_PHYSICAL_ADDR using a signed
+comparison currently (using jge instruction).
+
+When loading a 64-bit kernel using the new efi32_pe_entry() point added by:
+
+ 97aa276579b2 ("efi/x86: Add true mixed mode entry point into .compat section")
+
+using Qemu with -m 3072, the firmware actually loads us above 2Gb,
+resulting in a very early crash.
+
+Use the JAE instruction to perform a unsigned comparison instead, as physical
+addresses should be considered unsigned.
+
+Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/20200301230436.2246909-6-nivedita@alum.mit.edu
+Link: https://lore.kernel.org/r/20200308080859.21568-14-ardb@kernel.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/boot/compressed/head_32.S | 2 +-
+ arch/x86/boot/compressed/head_64.S | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S
+index 73f17d0544dd5..7f7e8b8518fec 100644
+--- a/arch/x86/boot/compressed/head_32.S
++++ b/arch/x86/boot/compressed/head_32.S
+@@ -106,7 +106,7 @@ SYM_FUNC_START(startup_32)
+ notl %eax
+ andl %eax, %ebx
+ cmpl $LOAD_PHYSICAL_ADDR, %ebx
+- jge 1f
++ jae 1f
+ #endif
+ movl $LOAD_PHYSICAL_ADDR, %ebx
+ 1:
+diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
+index 1f1f6c8139b38..afde2aa8382e9 100644
+--- a/arch/x86/boot/compressed/head_64.S
++++ b/arch/x86/boot/compressed/head_64.S
+@@ -106,7 +106,7 @@ SYM_FUNC_START(startup_32)
+ notl %eax
+ andl %eax, %ebx
+ cmpl $LOAD_PHYSICAL_ADDR, %ebx
+- jge 1f
++ jae 1f
+ #endif
+ movl $LOAD_PHYSICAL_ADDR, %ebx
+ 1:
+@@ -296,7 +296,7 @@ SYM_CODE_START(startup_64)
+ notq %rax
+ andq %rax, %rbp
+ cmpq $LOAD_PHYSICAL_ADDR, %rbp
+- jge 1f
++ jae 1f
+ #endif
+ movq $LOAD_PHYSICAL_ADDR, %rbp
+ 1:
+--
+2.20.1
+
--- /dev/null
+From bf03312ce8ca0eda7e3be22bcec81e7d468b22b7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Mar 2020 12:45:26 +0100
+Subject: x86: Don't let pgprot_modify() change the page encryption bit
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+[ Upstream commit 6db73f17c5f155dbcfd5e48e621c706270b84df0 ]
+
+When SEV or SME is enabled and active, vm_get_page_prot() typically
+returns with the encryption bit set. This means that users of
+pgprot_modify(, vm_get_page_prot()) (mprotect_fixup(), do_mmap()) end up
+with a value of vma->vm_pg_prot that is not consistent with the intended
+protection of the PTEs.
+
+This is also important for fault handlers that rely on the VMA
+vm_page_prot to set the page protection. Fix this by not allowing
+pgprot_modify() to change the encryption bit, similar to how it's done
+for PAT bits.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
+Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
+Link: https://lkml.kernel.org/r/20200304114527.3636-2-thomas_os@shipmail.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/include/asm/pgtable.h | 7 +++++--
+ arch/x86/include/asm/pgtable_types.h | 2 +-
+ 2 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
+index 7e118660bbd98..64a03f226ab73 100644
+--- a/arch/x86/include/asm/pgtable.h
++++ b/arch/x86/include/asm/pgtable.h
+@@ -627,12 +627,15 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
+ return __pmd(val);
+ }
+
+-/* mprotect needs to preserve PAT bits when updating vm_page_prot */
++/*
++ * mprotect needs to preserve PAT and encryption bits when updating
++ * vm_page_prot
++ */
+ #define pgprot_modify pgprot_modify
+ static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
+ {
+ pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
+- pgprotval_t addbits = pgprot_val(newprot);
++ pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK;
+ return __pgprot(preservebits | addbits);
+ }
+
+diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
+index 0239998d8cdc0..65c2ecd730c5b 100644
+--- a/arch/x86/include/asm/pgtable_types.h
++++ b/arch/x86/include/asm/pgtable_types.h
+@@ -118,7 +118,7 @@
+ */
+ #define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \
+ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY | \
+- _PAGE_SOFT_DIRTY | _PAGE_DEVMAP)
++ _PAGE_SOFT_DIRTY | _PAGE_DEVMAP | _PAGE_ENC)
+ #define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)
+
+ /*
+--
+2.20.1
+
--- /dev/null
+From 6309be0da846b674bf9914b51cc2584a26ba3f05 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 12 Mar 2020 16:45:09 +0200
+Subject: xhci: bail out early if driver can't accress host in resume
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+[ Upstream commit 72ae194704da212e2ec312ab182a96799d070755 ]
+
+Bail out early if the xHC host needs to be reset at resume
+but driver can't access xHC PCI registers.
+
+If xhci driver already fails to reset the controller then there
+is no point in attempting to free, re-initialize, re-allocate and
+re-start the host. If failure to access the host is detected later,
+failing the resume, xhci interrupts will be double freed
+when remove is called.
+
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20200312144517.1593-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/xhci.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
+index dbac0fa9748d5..fe38275363e0f 100644
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -1157,8 +1157,10 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
+ xhci_dbg(xhci, "Stop HCD\n");
+ xhci_halt(xhci);
+ xhci_zero_64b_regs(xhci);
+- xhci_reset(xhci);
++ retval = xhci_reset(xhci);
+ spin_unlock_irq(&xhci->lock);
++ if (retval)
++ return retval;
+ xhci_cleanup_msix(xhci);
+
+ xhci_dbg(xhci, "// Disabling event ring interrupts\n");
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
