--- /dev/null
+From 1d31999cf04c21709f72ceb17e65b54a401330da Mon Sep 17 00:00:00 2001
+From: Chester Lin <clin@suse.com>
+Date: Fri, 30 Aug 2019 14:30:07 +0100
+Subject: ARM: 8904/1: skip nomap memblocks while finding the lowmem/highmem boundary
+
+From: Chester Lin <clin@suse.com>
+
+commit 1d31999cf04c21709f72ceb17e65b54a401330da upstream.
+
+adjust_lowmem_bounds() checks every memblocks in order to find the boundary
+between lowmem and highmem. However some memblocks could be marked as NOMAP
+so they are not used by kernel, which should be skipped while calculating
+the boundary.
+
+Signed-off-by: Chester Lin <clin@suse.com>
+Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mm/mmu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/arm/mm/mmu.c
++++ b/arch/arm/mm/mmu.c
+@@ -1195,6 +1195,9 @@ void __init adjust_lowmem_bounds(void)
+ phys_addr_t block_start = reg->base;
+ phys_addr_t block_end = reg->base + reg->size;
+
++ if (memblock_is_nomap(reg))
++ continue;
++
+ if (reg->base < vmalloc_limit) {
+ if (block_end > lowmem_limit)
+ /*
--- /dev/null
+From e4ba15debcfd27f60d43da940a58108783bff2a6 Mon Sep 17 00:00:00 2001
+From: Hari Vyas <hari.vyas@broadcom.com>
+Date: Tue, 7 Aug 2018 16:33:48 +0530
+Subject: arm64: fix for bad_mode() handler to always result in panic
+
+From: Hari Vyas <hari.vyas@broadcom.com>
+
+commit e4ba15debcfd27f60d43da940a58108783bff2a6 upstream.
+
+The bad_mode() handler is called if we encounter an uunknown exception,
+with the expectation that the subsequent call to panic() will halt the
+system. Unfortunately, if the exception calling bad_mode() is taken from
+EL0, then the call to die() can end up killing the current user task and
+calling schedule() instead of falling through to panic().
+
+Remove the die() call altogether, since we really want to bring down the
+machine in this "impossible" case.
+
+Signed-off-by: Hari Vyas <hari.vyas@broadcom.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/traps.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm64/kernel/traps.c
++++ b/arch/arm64/kernel/traps.c
+@@ -648,7 +648,6 @@ asmlinkage void bad_mode(struct pt_regs
+ handler[reason], smp_processor_id(), esr,
+ esr_get_class_string(esr));
+
+- die("Oops - bad mode", regs, 0);
+ local_irq_disable();
+ panic("bad mode");
+ }
--- /dev/null
+From 703cbaa601ff3fb554d1246c336ba727cc083ea0 Mon Sep 17 00:00:00 2001
+From: Bo Yan <byan@nvidia.com>
+Date: Tue, 23 Jan 2018 13:57:55 -0800
+Subject: cpufreq: Skip cpufreq resume if it's not suspended
+
+From: Bo Yan <byan@nvidia.com>
+
+commit 703cbaa601ff3fb554d1246c336ba727cc083ea0 upstream.
+
+cpufreq_resume can be called even without preceding cpufreq_suspend.
+This can happen in following scenario:
+
+ suspend_devices_and_enter
+ --> dpm_suspend_start
+ --> dpm_prepare
+ --> device_prepare : this function errors out
+ --> dpm_suspend: this is skipped due to dpm_prepare failure
+ this means cpufreq_suspend is skipped over
+ --> goto Recover_platform, due to previous error
+ --> goto Resume_devices
+ --> dpm_resume_end
+ --> dpm_resume
+ --> cpufreq_resume
+
+In case schedutil is used as frequency governor, cpufreq_resume will
+eventually call sugov_start, which does following:
+
+ memset(sg_cpu, 0, sizeof(*sg_cpu));
+ ....
+
+This effectively erases function pointer for frequency update, causing
+crash later on. The function pointer would have been set correctly if
+subsequent cpufreq_add_update_util_hook runs successfully, but that
+function returns earlier because cpufreq_suspend was not called:
+
+ if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
+ return;
+
+The fix is to check cpufreq_suspended first, if it's false, that means
+cpufreq_suspend was not called in the first place, so do not resume
+cpufreq.
+
+Signed-off-by: Bo Yan <byan@nvidia.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+[ rjw: Dropped printing a message ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/cpufreq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -1673,6 +1673,9 @@ void cpufreq_resume(void)
+ if (!cpufreq_driver)
+ return;
+
++ if (unlikely(!cpufreq_suspended))
++ return;
++
+ cpufreq_suspended = false;
+
+ if (!has_target() && !cpufreq_driver->resume)
--- /dev/null
+From a634644751c46238df58bbfe992e30c1668388db Mon Sep 17 00:00:00 2001
+From: Gang He <ghe@suse.com>
+Date: Fri, 2 Nov 2018 15:48:03 -0700
+Subject: ocfs2: remove ocfs2_is_o2cb_active()
+
+From: Gang He <ghe@suse.com>
+
+commit a634644751c46238df58bbfe992e30c1668388db upstream.
+
+Remove ocfs2_is_o2cb_active(). We have similar functions to identify
+which cluster stack is being used via osb->osb_cluster_stack.
+
+Secondly, the current implementation of ocfs2_is_o2cb_active() is not
+totally safe. Based on the design of stackglue, we need to get
+ocfs2_stack_lock before using ocfs2_stack related data structures, and
+that active_stack pointer can be NULL in the case of mount failure.
+
+Link: http://lkml.kernel.org/r/1495441079-11708-1-git-send-email-ghe@suse.com
+Signed-off-by: Gang He <ghe@suse.com>
+Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
+Reviewed-by: Eric Ren <zren@suse.com>
+Acked-by: Changwei Ge <ge.changwei@h3c.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/dlmglue.c | 2 +-
+ fs/ocfs2/stackglue.c | 6 ------
+ fs/ocfs2/stackglue.h | 3 ---
+ 3 files changed, 1 insertion(+), 10 deletions(-)
+
+--- a/fs/ocfs2/dlmglue.c
++++ b/fs/ocfs2/dlmglue.c
+@@ -3422,7 +3422,7 @@ static int ocfs2_downconvert_lock(struct
+ * we can recover correctly from node failure. Otherwise, we may get
+ * invalid LVB in LKB, but without DLM_SBF_VALNOTVALID being set.
+ */
+- if (!ocfs2_is_o2cb_active() &&
++ if (ocfs2_userspace_stack(osb) &&
+ lockres->l_ops->flags & LOCK_TYPE_USES_LVB)
+ lvb = 1;
+
+--- a/fs/ocfs2/stackglue.c
++++ b/fs/ocfs2/stackglue.c
+@@ -48,12 +48,6 @@ static char ocfs2_hb_ctl_path[OCFS2_MAX_
+ */
+ static struct ocfs2_stack_plugin *active_stack;
+
+-inline int ocfs2_is_o2cb_active(void)
+-{
+- return !strcmp(active_stack->sp_name, OCFS2_STACK_PLUGIN_O2CB);
+-}
+-EXPORT_SYMBOL_GPL(ocfs2_is_o2cb_active);
+-
+ static struct ocfs2_stack_plugin *ocfs2_stack_lookup(const char *name)
+ {
+ struct ocfs2_stack_plugin *p;
+--- a/fs/ocfs2/stackglue.h
++++ b/fs/ocfs2/stackglue.h
+@@ -298,9 +298,6 @@ void ocfs2_stack_glue_set_max_proto_vers
+ int ocfs2_stack_glue_register(struct ocfs2_stack_plugin *plugin);
+ void ocfs2_stack_glue_unregister(struct ocfs2_stack_plugin *plugin);
+
+-/* In ocfs2_downconvert_lock(), we need to know which stack we are using */
+-int ocfs2_is_o2cb_active(void);
+-
+ extern struct kset *ocfs2_kset;
+
+ #endif /* STACKGLUE_H */
mm-memory_hotplug-don-t-access-uninitialized-memmaps-in-shrink_zone_span.patch
net-phy-dp83867-fix-speed-10-in-sgmii-mode.patch
net-phy-dp83867-increase-sgmii-autoneg-timer-duration.patch
+arm64-fix-for-bad_mode-handler-to-always-result-in-panic.patch
+cpufreq-skip-cpufreq-resume-if-it-s-not-suspended.patch
+ocfs2-remove-ocfs2_is_o2cb_active.patch
+arm-8904-1-skip-nomap-memblocks-while-finding-the-lowmem-highmem-boundary.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
