--- /dev/null
+From 31f3010e60522ede237fb145a63b4af5a41718c2 Mon Sep 17 00:00:00 2001
+From: Olof Johansson <olof@lixom.net>
+Date: Wed, 18 Dec 2019 01:18:49 +0100
+Subject: ARM: 8949/1: mm: mark free_memmap as __init
+
+From: Olof Johansson <olof@lixom.net>
+
+commit 31f3010e60522ede237fb145a63b4af5a41718c2 upstream.
+
+As of commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
+forcibly"), free_memmap() might not always be inlined, and thus is
+triggering a section warning:
+
+WARNING: vmlinux.o(.text.unlikely+0x904): Section mismatch in reference from the function free_memmap() to the function .meminit.text:memblock_free()
+
+Mark it as __init, since the faller (free_unused_memmap) already is.
+
+Fixes: ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly")
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mm/init.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/mm/init.c
++++ b/arch/arm/mm/init.c
+@@ -324,7 +324,7 @@ static inline void poison_init_mem(void
+ *p++ = 0xe7fddef0;
+ }
+
+-static inline void
++static inline void __init
+ free_memmap(unsigned long start_pfn, unsigned long end_pfn)
+ {
+ struct page *start_pg, *end_pg;
--- /dev/null
+From ec6e618c8c018c1361d77789a100a5f6f6317178 Mon Sep 17 00:00:00 2001
+From: Claudiu Beznea <claudiu.beznea@microchip.com>
+Date: Wed, 11 Dec 2019 13:04:08 +0200
+Subject: ARM: at91: pm: use of_device_id array to find the proper shdwc node
+
+From: Claudiu Beznea <claudiu.beznea@microchip.com>
+
+commit ec6e618c8c018c1361d77789a100a5f6f6317178 upstream.
+
+Use of_device_id array to find the proper shdwc compatibile node.
+SAM9X60's shdwc changes were not integrated when
+commit eaedc0d379da ("ARM: at91: pm: add ULP1 support for SAM9X60")
+was integrated.
+
+Fixes: eaedc0d379da ("ARM: at91: pm: add ULP1 support for SAM9X60")
+Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Link: https://lore.kernel.org/r/1576062248-18514-3-git-send-email-claudiu.beznea@microchip.com
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-at91/pm.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-at91/pm.c
++++ b/arch/arm/mach-at91/pm.c
+@@ -691,6 +691,12 @@ static void __init at91_pm_use_default_m
+ soc_pm.data.suspend_mode = AT91_PM_ULP0;
+ }
+
++static const struct of_device_id atmel_shdwc_ids[] = {
++ { .compatible = "atmel,sama5d2-shdwc" },
++ { .compatible = "microchip,sam9x60-shdwc" },
++ { /* sentinel. */ }
++};
++
+ static void __init at91_pm_modes_init(void)
+ {
+ struct device_node *np;
+@@ -700,7 +706,7 @@ static void __init at91_pm_modes_init(vo
+ !at91_is_pm_mode_active(AT91_PM_ULP1))
+ return;
+
+- np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-shdwc");
++ np = of_find_matching_node(NULL, atmel_shdwc_ids);
+ if (!np) {
+ pr_warn("%s: failed to find shdwc!\n", __func__);
+ goto ulp1_default;
--- /dev/null
+From 6b9dfd986a81a999a27b6ed9dbe91203089c62dd Mon Sep 17 00:00:00 2001
+From: Claudiu Beznea <claudiu.beznea@microchip.com>
+Date: Wed, 11 Dec 2019 13:04:07 +0200
+Subject: ARM: at91: pm: use SAM9X60 PMC's compatible
+
+From: Claudiu Beznea <claudiu.beznea@microchip.com>
+
+commit 6b9dfd986a81a999a27b6ed9dbe91203089c62dd upstream.
+
+SAM9X60 PMC's has a different PMC. It was not integrated at the moment
+commit 01c7031cfa73 ("ARM: at91: pm: initial PM support for SAM9X60")
+was published.
+
+Fixes: 01c7031cfa73 ("ARM: at91: pm: initial PM support for SAM9X60")
+Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Link: https://lore.kernel.org/r/1576062248-18514-2-git-send-email-claudiu.beznea@microchip.com
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-at91/pm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/mach-at91/pm.c
++++ b/arch/arm/mach-at91/pm.c
+@@ -751,6 +751,7 @@ static const struct of_device_id atmel_p
+ { .compatible = "atmel,sama5d3-pmc", .data = &pmc_infos[1] },
+ { .compatible = "atmel,sama5d4-pmc", .data = &pmc_infos[1] },
+ { .compatible = "atmel,sama5d2-pmc", .data = &pmc_infos[1] },
++ { .compatible = "microchip,sam9x60-pmc", .data = &pmc_infos[1] },
+ { /* sentinel */ },
+ };
+
--- /dev/null
+From 449443c03d8cfdacf7313e17779a2594ebf87e6d Mon Sep 17 00:00:00 2001
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+Date: Mon, 13 Jan 2020 23:30:19 +0000
+Subject: arm64: cpufeature: Fix the type of no FP/SIMD capability
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+commit 449443c03d8cfdacf7313e17779a2594ebf87e6d upstream.
+
+The NO_FPSIMD capability is defined with scope SYSTEM, which implies
+that the "absence" of FP/SIMD on at least one CPU is detected only
+after all the SMP CPUs are brought up. However, we use the status
+of this capability for every context switch. So, let us change
+the scope to LOCAL_CPU to allow the detection of this capability
+as and when the first CPU without FP is brought up.
+
+Also, the current type allows hotplugged CPU to be brought up without
+FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace
+up. Fix both of these issues by changing the capability to
+BOOT_RESTRICTED_LOCAL_CPU_FEATURE.
+
+Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
+Cc: Will Deacon <will@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/cpufeature.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/kernel/cpufeature.c
++++ b/arch/arm64/kernel/cpufeature.c
+@@ -1368,7 +1368,7 @@ static const struct arm64_cpu_capabiliti
+ {
+ /* FP/SIMD is not implemented */
+ .capability = ARM64_HAS_NO_FPSIMD,
+- .type = ARM64_CPUCAP_SYSTEM_FEATURE,
++ .type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE,
+ .min_field_value = 0,
+ .matches = has_no_fpsimd,
+ },
--- /dev/null
+From 7559950aef1ab8792c50797c6c5c7c5150a02460 Mon Sep 17 00:00:00 2001
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+Date: Mon, 13 Jan 2020 23:30:20 +0000
+Subject: arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+commit 7559950aef1ab8792c50797c6c5c7c5150a02460 upstream.
+
+We set the compat_elf_hwcap bits unconditionally on arm64 to
+include the VFP and NEON support. However, the FP/SIMD unit
+is optional on Arm v8 and thus could be missing. We already
+handle this properly in the kernel, but still advertise to
+the COMPAT applications that the VFP is available. Fix this
+to make sure we only advertise when we really have them.
+
+Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
+Cc: Will Deacon <will@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/cpufeature.c | 37 ++++++++++++++++++++++++++++++++++---
+ 1 file changed, 34 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/kernel/cpufeature.c
++++ b/arch/arm64/kernel/cpufeature.c
+@@ -32,9 +32,7 @@ static unsigned long elf_hwcap __read_mo
+ #define COMPAT_ELF_HWCAP_DEFAULT \
+ (COMPAT_HWCAP_HALF|COMPAT_HWCAP_THUMB|\
+ COMPAT_HWCAP_FAST_MULT|COMPAT_HWCAP_EDSP|\
+- COMPAT_HWCAP_TLS|COMPAT_HWCAP_VFP|\
+- COMPAT_HWCAP_VFPv3|COMPAT_HWCAP_VFPv4|\
+- COMPAT_HWCAP_NEON|COMPAT_HWCAP_IDIV|\
++ COMPAT_HWCAP_TLS|COMPAT_HWCAP_IDIV|\
+ COMPAT_HWCAP_LPAE)
+ unsigned int compat_elf_hwcap __read_mostly = COMPAT_ELF_HWCAP_DEFAULT;
+ unsigned int compat_elf_hwcap2 __read_mostly;
+@@ -1596,6 +1594,12 @@ static const struct arm64_cpu_capabiliti
+ .match_list = list, \
+ }
+
++#define HWCAP_CAP_MATCH(match, cap_type, cap) \
++ { \
++ __HWCAP_CAP(#cap, cap_type, cap) \
++ .matches = match, \
++ }
++
+ #ifdef CONFIG_ARM64_PTR_AUTH
+ static const struct arm64_cpu_capabilities ptr_auth_hwcap_addr_matches[] = {
+ {
+@@ -1669,8 +1673,35 @@ static const struct arm64_cpu_capabiliti
+ {},
+ };
+
++#ifdef CONFIG_COMPAT
++static bool compat_has_neon(const struct arm64_cpu_capabilities *cap, int scope)
++{
++ /*
++ * Check that all of MVFR1_EL1.{SIMDSP, SIMDInt, SIMDLS} are available,
++ * in line with that of arm32 as in vfp_init(). We make sure that the
++ * check is future proof, by making sure value is non-zero.
++ */
++ u32 mvfr1;
++
++ WARN_ON(scope == SCOPE_LOCAL_CPU && preemptible());
++ if (scope == SCOPE_SYSTEM)
++ mvfr1 = read_sanitised_ftr_reg(SYS_MVFR1_EL1);
++ else
++ mvfr1 = read_sysreg_s(SYS_MVFR1_EL1);
++
++ return cpuid_feature_extract_unsigned_field(mvfr1, MVFR1_SIMDSP_SHIFT) &&
++ cpuid_feature_extract_unsigned_field(mvfr1, MVFR1_SIMDINT_SHIFT) &&
++ cpuid_feature_extract_unsigned_field(mvfr1, MVFR1_SIMDLS_SHIFT);
++}
++#endif
++
+ static const struct arm64_cpu_capabilities compat_elf_hwcaps[] = {
+ #ifdef CONFIG_COMPAT
++ HWCAP_CAP_MATCH(compat_has_neon, CAP_COMPAT_HWCAP, COMPAT_HWCAP_NEON),
++ HWCAP_CAP(SYS_MVFR1_EL1, MVFR1_SIMDFMAC_SHIFT, FTR_UNSIGNED, 1, CAP_COMPAT_HWCAP, COMPAT_HWCAP_VFPv4),
++ /* Arm v8 mandates MVFR0.FPDP == {0, 2}. So, piggy back on this for the presence of VFP support */
++ HWCAP_CAP(SYS_MVFR0_EL1, MVFR0_FPDP_SHIFT, FTR_UNSIGNED, 2, CAP_COMPAT_HWCAP, COMPAT_HWCAP_VFP),
++ HWCAP_CAP(SYS_MVFR0_EL1, MVFR0_FPDP_SHIFT, FTR_UNSIGNED, 2, CAP_COMPAT_HWCAP, COMPAT_HWCAP_VFPv3),
+ HWCAP_CAP(SYS_ID_ISAR5_EL1, ID_ISAR5_AES_SHIFT, FTR_UNSIGNED, 2, CAP_COMPAT_HWCAP2, COMPAT_HWCAP2_PMULL),
+ HWCAP_CAP(SYS_ID_ISAR5_EL1, ID_ISAR5_AES_SHIFT, FTR_UNSIGNED, 1, CAP_COMPAT_HWCAP2, COMPAT_HWCAP2_AES),
+ HWCAP_CAP(SYS_ID_ISAR5_EL1, ID_ISAR5_SHA1_SHIFT, FTR_UNSIGNED, 1, CAP_COMPAT_HWCAP2, COMPAT_HWCAP2_SHA1),
--- /dev/null
+From 73d6890fe8ff40e357039b626537ac82d8782aeb Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@kernel.org>
+Date: Fri, 10 Jan 2020 15:50:04 +0000
+Subject: arm64: kernel: Correct annotation of end of el0_sync
+
+From: Mark Brown <broonie@kernel.org>
+
+commit 73d6890fe8ff40e357039b626537ac82d8782aeb upstream.
+
+Commit 582f95835a8fc812c ("arm64: entry: convert el0_sync to C") caused
+the ENDPROC() annotating the end of el0_sync to be placed after the code
+for el0_sync_compat. This replaced the previous annotation where it was
+located after all the cases that are now converted to C, including after
+the currently unannotated el0_irq_compat and el0_error_compat. Move the
+annotation to the end of the function and add separate annotations for
+the _compat ones.
+
+Fixes: 582f95835a8fc812c (arm64: entry: convert el0_sync to C)
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/entry.S | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/kernel/entry.S
++++ b/arch/arm64/kernel/entry.S
+@@ -653,6 +653,7 @@ el0_sync:
+ mov x0, sp
+ bl el0_sync_handler
+ b ret_to_user
++ENDPROC(el0_sync)
+
+ #ifdef CONFIG_COMPAT
+ .align 6
+@@ -661,16 +662,18 @@ el0_sync_compat:
+ mov x0, sp
+ bl el0_sync_compat_handler
+ b ret_to_user
+-ENDPROC(el0_sync)
++ENDPROC(el0_sync_compat)
+
+ .align 6
+ el0_irq_compat:
+ kernel_entry 0, 32
+ b el0_irq_naked
++ENDPROC(el0_irq_compat)
+
+ el0_error_compat:
+ kernel_entry 0, 32
+ b el0_error_naked
++ENDPROC(el0_error_compat)
+ #endif
+
+ .align 6
--- /dev/null
+From f5523423defb0d929e23813c8dd16c0131043a8c Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@armlinux.org.uk>
+Date: Sat, 28 Dec 2019 11:57:14 +0000
+Subject: arm64: kvm: Fix IDMAP overlap with HYP VA
+
+From: Russell King <rmk+kernel@armlinux.org.uk>
+
+commit f5523423defb0d929e23813c8dd16c0131043a8c upstream.
+
+Booting 5.4 on LX2160A reveals that KVM is non-functional:
+
+kvm: Limiting the IPA size due to kernel Virtual Address limit
+kvm [1]: IPA Size Limit: 43bits
+kvm [1]: IDMAP intersecting with HYP VA, unable to continue
+kvm [1]: error initializing Hyp mode: -22
+
+Debugging shows:
+
+kvm [1]: IDMAP page: 81a26000
+kvm [1]: HYP VA range: 0:22ffffffff
+
+as RAM is located at:
+
+80000000-fbdfffff : System RAM
+2080000000-237fffffff : System RAM
+
+Comparing this with the same kernel on Armada 8040 shows:
+
+kvm: Limiting the IPA size due to kernel Virtual Address limit
+kvm [1]: IPA Size Limit: 43bits
+kvm [1]: IDMAP page: 2a26000
+kvm [1]: HYP VA range: 4800000000:493fffffff
+...
+kvm [1]: Hyp mode initialized successfully
+
+which indicates that hyp_va_msb is set, and is always set to the
+opposite value of the idmap page to avoid the overlap. This does not
+happen with the LX2160A.
+
+Further debugging shows vabits_actual = 39, kva_msb = 38 on LX2160A and
+kva_msb = 33 on Armada 8040. Looking at the bit layout of the HYP VA,
+there is still one bit available for hyp_va_msb. Set this bit
+appropriately. This allows KVM to be functional on the LX2160A, but
+without any HYP VA randomisation:
+
+kvm: Limiting the IPA size due to kernel Virtual Address limit
+kvm [1]: IPA Size Limit: 43bits
+kvm [1]: IDMAP page: 81a24000
+kvm [1]: HYP VA range: 4000000000:62ffffffff
+...
+kvm [1]: Hyp mode initialized successfully
+
+Fixes: ed57cac83e05 ("arm64: KVM: Introduce EL2 VA randomisation")
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+[maz: small additional cleanups, preserved case where the tag
+ is legitimately 0 and we can just use the mask, Fixes tag]
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/E1ilAiY-0000MA-RG@rmk-PC.armlinux.org.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kvm/va_layout.c | 56 ++++++++++++++++++++-------------------------
+ 1 file changed, 25 insertions(+), 31 deletions(-)
+
+--- a/arch/arm64/kvm/va_layout.c
++++ b/arch/arm64/kvm/va_layout.c
+@@ -13,52 +13,46 @@
+ #include <asm/kvm_mmu.h>
+
+ /*
+- * The LSB of the random hyp VA tag or 0 if no randomization is used.
++ * The LSB of the HYP VA tag
+ */
+ static u8 tag_lsb;
+ /*
+- * The random hyp VA tag value with the region bit if hyp randomization is used
++ * The HYP VA tag value with the region bit
+ */
+ static u64 tag_val;
+ static u64 va_mask;
+
++/*
++ * We want to generate a hyp VA with the following format (with V ==
++ * vabits_actual):
++ *
++ * 63 ... V | V-1 | V-2 .. tag_lsb | tag_lsb - 1 .. 0
++ * ---------------------------------------------------------
++ * | 0000000 | hyp_va_msb | random tag | kern linear VA |
++ * |--------- tag_val -----------|----- va_mask ---|
++ *
++ * which does not conflict with the idmap regions.
++ */
+ __init void kvm_compute_layout(void)
+ {
+ phys_addr_t idmap_addr = __pa_symbol(__hyp_idmap_text_start);
+ u64 hyp_va_msb;
+- int kva_msb;
+
+ /* Where is my RAM region? */
+ hyp_va_msb = idmap_addr & BIT(vabits_actual - 1);
+ hyp_va_msb ^= BIT(vabits_actual - 1);
+
+- kva_msb = fls64((u64)phys_to_virt(memblock_start_of_DRAM()) ^
++ tag_lsb = fls64((u64)phys_to_virt(memblock_start_of_DRAM()) ^
+ (u64)(high_memory - 1));
+
+- if (kva_msb == (vabits_actual - 1)) {
+- /*
+- * No space in the address, let's compute the mask so
+- * that it covers (vabits_actual - 1) bits, and the region
+- * bit. The tag stays set to zero.
+- */
+- va_mask = BIT(vabits_actual - 1) - 1;
+- va_mask |= hyp_va_msb;
+- } else {
+- /*
+- * We do have some free bits to insert a random tag.
+- * Hyp VAs are now created from kernel linear map VAs
+- * using the following formula (with V == vabits_actual):
+- *
+- * 63 ... V | V-1 | V-2 .. tag_lsb | tag_lsb - 1 .. 0
+- * ---------------------------------------------------------
+- * | 0000000 | hyp_va_msb | random tag | kern linear VA |
+- */
+- tag_lsb = kva_msb;
+- va_mask = GENMASK_ULL(tag_lsb - 1, 0);
+- tag_val = get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
+- tag_val |= hyp_va_msb;
+- tag_val >>= tag_lsb;
++ va_mask = GENMASK_ULL(tag_lsb - 1, 0);
++ tag_val = hyp_va_msb;
++
++ if (tag_lsb != (vabits_actual - 1)) {
++ /* We have some free bits to insert a random tag. */
++ tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
+ }
++ tag_val >>= tag_lsb;
+ }
+
+ static u32 compute_instruction(int n, u32 rd, u32 rn)
+@@ -117,11 +111,11 @@ void __init kvm_update_va_mask(struct al
+ * VHE doesn't need any address translation, let's NOP
+ * everything.
+ *
+- * Alternatively, if we don't have any spare bits in
+- * the address, NOP everything after masking that
+- * kernel VA.
++ * Alternatively, if the tag is zero (because the layout
++ * dictates it and we don't have any spare bits in the
++ * address), NOP everything after masking the kernel VA.
+ */
+- if (has_vhe() || (!tag_lsb && i > 0)) {
++ if (has_vhe() || (!tag_val && i > 0)) {
+ updptr[i] = cpu_to_le32(aarch64_insn_gen_nop());
+ continue;
+ }
--- /dev/null
+From 52f73c383b2418f2d31b798e765ae7d596c35021 Mon Sep 17 00:00:00 2001
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+Date: Mon, 13 Jan 2020 23:30:23 +0000
+Subject: arm64: nofpsmid: Handle TIF_FOREIGN_FPSTATE flag cleanly
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+commit 52f73c383b2418f2d31b798e765ae7d596c35021 upstream.
+
+We detect the absence of FP/SIMD after an incapable CPU is brought up,
+and by then we have kernel threads running already with TIF_FOREIGN_FPSTATE set
+which could be set for early userspace applications (e.g, modprobe triggered
+from initramfs) and init. This could cause the applications to loop forever in
+do_nofity_resume() as we never clear the TIF flag, once we now know that
+we don't support FP.
+
+Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag
+for tasks which may have them set, as we would have done in the normal
+case, but avoiding touching the hardware state (since we don't support any).
+
+Also to make sure we handle the cases seemlessly we categorise the
+helper functions to two :
+ 1) Helpers for common core code, which calls into take appropriate
+ actions without knowing the current FPSIMD state of the CPU/task.
+
+ e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(),
+ fpsimd_save_and_flush_cpu_state().
+
+ We bail out early for these functions, taking any appropriate actions
+ (e.g, clearing the TIF flag) where necessary to hide the handling
+ from core code.
+
+ 2) Helpers used when the presence of FP/SIMD is apparent.
+ i.e, save/restore the FP/SIMD register state, modify the CPU/task
+ FP/SIMD state.
+ e.g,
+
+ fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD registers
+
+ fpsimd_bind_task_to_cpu() \
+ - Update the "state" metadata for CPU/task.
+ fpsimd_bind_state_to_cpu() /
+
+ fpsimd_update_current_state() - Update the fp/simd state for the current
+ task from memory.
+
+ These must not be called in the absence of FP/SIMD. Put in a WARNING
+ to make sure they are not invoked in the absence of FP/SIMD.
+
+KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD state
+on the CPU. However, without FP/SIMD support we trap all accesses and
+inject undefined instruction. Thus we should never "load" guest state.
+Add a sanity check to make sure this is valid.
+
+Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
+Cc: Will Deacon <will@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Acked-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/fpsimd.c | 30 +++++++++++++++++++++++++++---
+ arch/arm64/kvm/hyp/switch.c | 10 +++++++++-
+ 2 files changed, 36 insertions(+), 4 deletions(-)
+
+--- a/arch/arm64/kernel/fpsimd.c
++++ b/arch/arm64/kernel/fpsimd.c
+@@ -269,6 +269,7 @@ static void sve_free(struct task_struct
+ */
+ static void task_fpsimd_load(void)
+ {
++ WARN_ON(!system_supports_fpsimd());
+ WARN_ON(!have_cpu_fpsimd_context());
+
+ if (system_supports_sve() && test_thread_flag(TIF_SVE))
+@@ -289,6 +290,7 @@ static void fpsimd_save(void)
+ this_cpu_ptr(&fpsimd_last_state);
+ /* set by fpsimd_bind_task_to_cpu() or fpsimd_bind_state_to_cpu() */
+
++ WARN_ON(!system_supports_fpsimd());
+ WARN_ON(!have_cpu_fpsimd_context());
+
+ if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
+@@ -1092,6 +1094,7 @@ void fpsimd_bind_task_to_cpu(void)
+ struct fpsimd_last_state_struct *last =
+ this_cpu_ptr(&fpsimd_last_state);
+
++ WARN_ON(!system_supports_fpsimd());
+ last->st = ¤t->thread.uw.fpsimd_state;
+ last->sve_state = current->thread.sve_state;
+ last->sve_vl = current->thread.sve_vl;
+@@ -1114,6 +1117,7 @@ void fpsimd_bind_state_to_cpu(struct use
+ struct fpsimd_last_state_struct *last =
+ this_cpu_ptr(&fpsimd_last_state);
+
++ WARN_ON(!system_supports_fpsimd());
+ WARN_ON(!in_softirq() && !irqs_disabled());
+
+ last->st = st;
+@@ -1128,8 +1132,19 @@ void fpsimd_bind_state_to_cpu(struct use
+ */
+ void fpsimd_restore_current_state(void)
+ {
+- if (!system_supports_fpsimd())
++ /*
++ * For the tasks that were created before we detected the absence of
++ * FP/SIMD, the TIF_FOREIGN_FPSTATE could be set via fpsimd_thread_switch(),
++ * e.g, init. This could be then inherited by the children processes.
++ * If we later detect that the system doesn't support FP/SIMD,
++ * we must clear the flag for all the tasks to indicate that the
++ * FPSTATE is clean (as we can't have one) to avoid looping for ever in
++ * do_notify_resume().
++ */
++ if (!system_supports_fpsimd()) {
++ clear_thread_flag(TIF_FOREIGN_FPSTATE);
+ return;
++ }
+
+ get_cpu_fpsimd_context();
+
+@@ -1148,7 +1163,7 @@ void fpsimd_restore_current_state(void)
+ */
+ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
+ {
+- if (!system_supports_fpsimd())
++ if (WARN_ON(!system_supports_fpsimd()))
+ return;
+
+ get_cpu_fpsimd_context();
+@@ -1179,7 +1194,13 @@ void fpsimd_update_current_state(struct
+ void fpsimd_flush_task_state(struct task_struct *t)
+ {
+ t->thread.fpsimd_cpu = NR_CPUS;
+-
++ /*
++ * If we don't support fpsimd, bail out after we have
++ * reset the fpsimd_cpu for this task and clear the
++ * FPSTATE.
++ */
++ if (!system_supports_fpsimd())
++ return;
+ barrier();
+ set_tsk_thread_flag(t, TIF_FOREIGN_FPSTATE);
+
+@@ -1193,6 +1214,7 @@ void fpsimd_flush_task_state(struct task
+ */
+ static void fpsimd_flush_cpu_state(void)
+ {
++ WARN_ON(!system_supports_fpsimd());
+ __this_cpu_write(fpsimd_last_state.st, NULL);
+ set_thread_flag(TIF_FOREIGN_FPSTATE);
+ }
+@@ -1203,6 +1225,8 @@ static void fpsimd_flush_cpu_state(void)
+ */
+ void fpsimd_save_and_flush_cpu_state(void)
+ {
++ if (!system_supports_fpsimd())
++ return;
+ WARN_ON(preemptible());
+ __get_cpu_fpsimd_context();
+ fpsimd_save();
+--- a/arch/arm64/kvm/hyp/switch.c
++++ b/arch/arm64/kvm/hyp/switch.c
+@@ -28,7 +28,15 @@
+ /* Check whether the FP regs were dirtied while in the host-side run loop: */
+ static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu)
+ {
+- if (vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE)
++ /*
++ * When the system doesn't support FP/SIMD, we cannot rely on
++ * the _TIF_FOREIGN_FPSTATE flag. However, we always inject an
++ * abort on the very first access to FP and thus we should never
++ * see KVM_ARM64_FP_ENABLED. For added safety, make sure we always
++ * trap the accesses.
++ */
++ if (!system_supports_fpsimd() ||
++ vcpu->arch.host_thread_info->flags & _TIF_FOREIGN_FPSTATE)
+ vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED |
+ KVM_ARM64_FP_HOST);
+
--- /dev/null
+From c9d66999f064947e6b577ceacc1eb2fbca6a8d3c Mon Sep 17 00:00:00 2001
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+Date: Mon, 13 Jan 2020 23:30:21 +0000
+Subject: arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations
+
+From: Suzuki K Poulose <suzuki.poulose@arm.com>
+
+commit c9d66999f064947e6b577ceacc1eb2fbca6a8d3c upstream.
+
+When fp/simd is not supported on the system, fail the operations
+of FP/SIMD regsets.
+
+Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
+Cc: Will Deacon <will@kernel.org>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/ptrace.c | 21 +++++++++++++++++++++
+ 1 file changed, 21 insertions(+)
+
+--- a/arch/arm64/kernel/ptrace.c
++++ b/arch/arm64/kernel/ptrace.c
+@@ -615,6 +615,13 @@ static int gpr_set(struct task_struct *t
+ return 0;
+ }
+
++static int fpr_active(struct task_struct *target, const struct user_regset *regset)
++{
++ if (!system_supports_fpsimd())
++ return -ENODEV;
++ return regset->n;
++}
++
+ /*
+ * TODO: update fp accessors for lazy context switching (sync/flush hwstate)
+ */
+@@ -637,6 +644,9 @@ static int fpr_get(struct task_struct *t
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+ {
++ if (!system_supports_fpsimd())
++ return -EINVAL;
++
+ if (target == current)
+ fpsimd_preserve_current_state();
+
+@@ -676,6 +686,9 @@ static int fpr_set(struct task_struct *t
+ {
+ int ret;
+
++ if (!system_supports_fpsimd())
++ return -EINVAL;
++
+ ret = __fpr_set(target, regset, pos, count, kbuf, ubuf, 0);
+ if (ret)
+ return ret;
+@@ -1134,6 +1147,7 @@ static const struct user_regset aarch64_
+ */
+ .size = sizeof(u32),
+ .align = sizeof(u32),
++ .active = fpr_active,
+ .get = fpr_get,
+ .set = fpr_set
+ },
+@@ -1348,6 +1362,9 @@ static int compat_vfp_get(struct task_st
+ compat_ulong_t fpscr;
+ int ret, vregs_end_pos;
+
++ if (!system_supports_fpsimd())
++ return -EINVAL;
++
+ uregs = &target->thread.uw.fpsimd_state;
+
+ if (target == current)
+@@ -1381,6 +1398,9 @@ static int compat_vfp_set(struct task_st
+ compat_ulong_t fpscr;
+ int ret, vregs_end_pos;
+
++ if (!system_supports_fpsimd())
++ return -EINVAL;
++
+ uregs = &target->thread.uw.fpsimd_state;
+
+ vregs_end_pos = VFP_STATE_SIZE - sizeof(compat_ulong_t);
+@@ -1438,6 +1458,7 @@ static const struct user_regset aarch32_
+ .n = VFP_STATE_SIZE / sizeof(compat_ulong_t),
+ .size = sizeof(compat_ulong_t),
+ .align = sizeof(compat_ulong_t),
++ .active = fpr_active,
+ .get = compat_vfp_get,
+ .set = compat_vfp_set
+ },
--- /dev/null
+From 130128098a4e5ce9a0dfbdf9a7e27a43579901fd Mon Sep 17 00:00:00 2001
+From: Shengjiu Wang <shengjiu.wang@nxp.com>
+Date: Mon, 20 Jan 2020 15:28:06 +0800
+Subject: ASoC: soc-generic-dmaengine-pcm: Fix error handling
+
+From: Shengjiu Wang <shengjiu.wang@nxp.com>
+
+commit 130128098a4e5ce9a0dfbdf9a7e27a43579901fd upstream.
+
+Remove the return value checking, that is to align with the code
+before adding snd_dmaengine_pcm_refine_runtime_hwparams function.
+
+Otherwise it causes a regression on the HiKey board:
+
+[ 17.721424] hi6210_i2s f7118000.i2s: ASoC: can't open component f7118000.i2s: -6
+
+Fixes: e957204e732b ("ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_refine_runtime_hwparams")
+Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
+Reported-by: John Stultz <john.stultz@linaro.org>
+Link: https://lore.kernel.org/r/1579505286-32085-1-git-send-email-shengjiu.wang@nxp.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/soc/soc-generic-dmaengine-pcm.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/sound/soc/soc-generic-dmaengine-pcm.c
++++ b/sound/soc/soc-generic-dmaengine-pcm.c
+@@ -117,7 +117,6 @@ dmaengine_pcm_set_runtime_hwparams(struc
+ struct dma_chan *chan = pcm->chan[substream->stream];
+ struct snd_dmaengine_dai_dma_data *dma_data;
+ struct snd_pcm_hardware hw;
+- int ret;
+
+ if (pcm->config && pcm->config->pcm_hardware)
+ return snd_soc_set_runtime_hwparams(substream,
+@@ -138,12 +137,15 @@ dmaengine_pcm_set_runtime_hwparams(struc
+ if (pcm->flags & SND_DMAENGINE_PCM_FLAG_NO_RESIDUE)
+ hw.info |= SNDRV_PCM_INFO_BATCH;
+
+- ret = snd_dmaengine_pcm_refine_runtime_hwparams(substream,
+- dma_data,
+- &hw,
+- chan);
+- if (ret)
+- return ret;
++ /**
++ * FIXME: Remove the return value check to align with the code
++ * before adding snd_dmaengine_pcm_refine_runtime_hwparams
++ * function.
++ */
++ snd_dmaengine_pcm_refine_runtime_hwparams(substream,
++ dma_data,
++ &hw,
++ chan);
+
+ return snd_soc_set_runtime_hwparams(substream, &hw);
+ }
--- /dev/null
+From 2aa8c529387c25606fdc1484154b92f8bfbc5746 Mon Sep 17 00:00:00 2001
+From: Coly Li <colyli@suse.de>
+Date: Fri, 24 Jan 2020 01:01:37 +0800
+Subject: bcache: avoid unnecessary btree nodes flushing in btree_flush_write()
+
+From: Coly Li <colyli@suse.de>
+
+commit 2aa8c529387c25606fdc1484154b92f8bfbc5746 upstream.
+
+the commit 91be66e1318f ("bcache: performance improvement for
+btree_flush_write()") was an effort to flushing btree node with oldest
+btree node faster in following methods,
+- Only iterate dirty btree nodes in c->btree_cache, avoid scanning a lot
+ of clean btree nodes.
+- Take c->btree_cache as a LRU-like list, aggressively flushing all
+ dirty nodes from tail of c->btree_cache util the btree node with
+ oldest journal entry is flushed. This is to reduce the time of holding
+ c->bucket_lock.
+
+Guoju Fang and Shuang Li reported that they observe unexptected extra
+write I/Os on cache device after applying the above patch. Guoju Fang
+provideed more detailed diagnose information that the aggressive
+btree nodes flushing may cause 10x more btree nodes to flush in his
+workload. He points out when system memory is large enough to hold all
+btree nodes in memory, c->btree_cache is not a LRU-like list any more.
+Then the btree node with oldest journal entry is very probably not-
+close to the tail of c->btree_cache list. In such situation much more
+dirty btree nodes will be aggressively flushed before the target node
+is flushed. When slow SATA SSD is used as cache device, such over-
+aggressive flushing behavior will cause performance regression.
+
+After spending a lot of time on debug and diagnose, I find the real
+condition is more complicated, aggressive flushing dirty btree nodes
+from tail of c->btree_cache list is not a good solution.
+- When all btree nodes are cached in memory, c->btree_cache is not
+ a LRU-like list, the btree nodes with oldest journal entry won't
+ be close to the tail of the list.
+- There can be hundreds dirty btree nodes reference the oldest journal
+ entry, before flushing all the nodes the oldest journal entry cannot
+ be reclaimed.
+When the above two conditions mixed together, a simply flushing from
+tail of c->btree_cache list is really NOT a good idea.
+
+Fortunately there is still chance to make btree_flush_write() work
+better. Here is how this patch avoids unnecessary btree nodes flushing,
+- Only acquire c->journal.lock when getting oldest journal entry of
+ fifo c->journal.pin. In rested locations check the journal entries
+ locklessly, so their values can be changed on other cores
+ in parallel.
+- In loop list_for_each_entry_safe_reverse(), checking latest front
+ point of fifo c->journal.pin. If it is different from the original
+ point which we get with locking c->journal.lock, it means the oldest
+ journal entry is reclaim on other cores. At this moment, all selected
+ dirty nodes recorded in array btree_nodes[] are all flushed and clean
+ on other CPU cores, it is unncessary to iterate c->btree_cache any
+ longer. Just quit the list_for_each_entry_safe_reverse() loop and
+ the following for-loop will skip all the selected clean nodes.
+- Find a proper time to quit the list_for_each_entry_safe_reverse()
+ loop. Check the refcount value of orignial fifo front point, if the
+ value is larger than selected node number of btree_nodes[], it means
+ more matching btree nodes should be scanned. Otherwise it means no
+ more matching btee nodes in rest of c->btree_cache list, the loop
+ can be quit. If the original oldest journal entry is reclaimed and
+ fifo front point is updated, the refcount of original fifo front point
+ will be 0, then the loop will be quit too.
+- Not hold c->bucket_lock too long time. c->bucket_lock is also required
+ for space allocation for cached data, hold it for too long time will
+ block regular I/O requests. When iterating list c->btree_cache, even
+ there are a lot of maching btree nodes, in order to not holding
+ c->bucket_lock for too long time, only BTREE_FLUSH_NR nodes are
+ selected and to flush in following for-loop.
+With this patch, only btree nodes referencing oldest journal entry
+are flushed to cache device, no aggressive flushing for unnecessary
+btree node any more. And in order to avoid blocking regluar I/O
+requests, each time when btree_flush_write() called, at most only
+BTREE_FLUSH_NR btree nodes are selected to flush, even there are more
+maching btree nodes in list c->btree_cache.
+
+At last, one more thing to explain: Why it is safe to read front point
+of c->journal.pin without holding c->journal.lock inside the
+list_for_each_entry_safe_reverse() loop ?
+
+Here is my answer: When reading the front point of fifo c->journal.pin,
+we don't need to know the exact value of front point, we just want to
+check whether the value is different from the original front point
+(which is accurate value because we get it while c->jouranl.lock is
+held). For such purpose, it works as expected without holding
+c->journal.lock. Even the front point is changed on other CPU core and
+not updated to local core, and current iterating btree node has
+identical journal entry local as original fetched fifo front point, it
+is still safe. Because after holding mutex b->write_lock (with memory
+barrier) this btree node can be found as clean and skipped, the loop
+will quite latter when iterate on next node of list c->btree_cache.
+
+Fixes: 91be66e1318f ("bcache: performance improvement for btree_flush_write()")
+Reported-by: Guoju Fang <fangguoju@gmail.com>
+Reported-by: Shuang Li <psymon@bonuscloud.io>
+Signed-off-by: Coly Li <colyli@suse.de>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/bcache/journal.c | 80 +++++++++++++++++++++++++++++++++++++++++---
+ 1 file changed, 75 insertions(+), 5 deletions(-)
+
+--- a/drivers/md/bcache/journal.c
++++ b/drivers/md/bcache/journal.c
+@@ -417,10 +417,14 @@ err:
+
+ /* Journalling */
+
++#define nr_to_fifo_front(p, front_p, mask) (((p) - (front_p)) & (mask))
++
+ static void btree_flush_write(struct cache_set *c)
+ {
+ struct btree *b, *t, *btree_nodes[BTREE_FLUSH_NR];
+- unsigned int i, n;
++ unsigned int i, nr, ref_nr;
++ atomic_t *fifo_front_p, *now_fifo_front_p;
++ size_t mask;
+
+ if (c->journal.btree_flushing)
+ return;
+@@ -433,12 +437,50 @@ static void btree_flush_write(struct cac
+ c->journal.btree_flushing = true;
+ spin_unlock(&c->journal.flush_write_lock);
+
++ /* get the oldest journal entry and check its refcount */
++ spin_lock(&c->journal.lock);
++ fifo_front_p = &fifo_front(&c->journal.pin);
++ ref_nr = atomic_read(fifo_front_p);
++ if (ref_nr <= 0) {
++ /*
++ * do nothing if no btree node references
++ * the oldest journal entry
++ */
++ spin_unlock(&c->journal.lock);
++ goto out;
++ }
++ spin_unlock(&c->journal.lock);
++
++ mask = c->journal.pin.mask;
++ nr = 0;
+ atomic_long_inc(&c->flush_write);
+ memset(btree_nodes, 0, sizeof(btree_nodes));
+- n = 0;
+
+ mutex_lock(&c->bucket_lock);
+ list_for_each_entry_safe_reverse(b, t, &c->btree_cache, list) {
++ /*
++ * It is safe to get now_fifo_front_p without holding
++ * c->journal.lock here, because we don't need to know
++ * the exactly accurate value, just check whether the
++ * front pointer of c->journal.pin is changed.
++ */
++ now_fifo_front_p = &fifo_front(&c->journal.pin);
++ /*
++ * If the oldest journal entry is reclaimed and front
++ * pointer of c->journal.pin changes, it is unnecessary
++ * to scan c->btree_cache anymore, just quit the loop and
++ * flush out what we have already.
++ */
++ if (now_fifo_front_p != fifo_front_p)
++ break;
++ /*
++ * quit this loop if all matching btree nodes are
++ * scanned and record in btree_nodes[] already.
++ */
++ ref_nr = atomic_read(fifo_front_p);
++ if (nr >= ref_nr)
++ break;
++
+ if (btree_node_journal_flush(b))
+ pr_err("BUG: flush_write bit should not be set here!");
+
+@@ -454,17 +496,44 @@ static void btree_flush_write(struct cac
+ continue;
+ }
+
++ /*
++ * Only select the btree node which exactly references
++ * the oldest journal entry.
++ *
++ * If the journal entry pointed by fifo_front_p is
++ * reclaimed in parallel, don't worry:
++ * - the list_for_each_xxx loop will quit when checking
++ * next now_fifo_front_p.
++ * - If there are matched nodes recorded in btree_nodes[],
++ * they are clean now (this is why and how the oldest
++ * journal entry can be reclaimed). These selected nodes
++ * will be ignored and skipped in the folowing for-loop.
++ */
++ if (nr_to_fifo_front(btree_current_write(b)->journal,
++ fifo_front_p,
++ mask) != 0) {
++ mutex_unlock(&b->write_lock);
++ continue;
++ }
++
+ set_btree_node_journal_flush(b);
+
+ mutex_unlock(&b->write_lock);
+
+- btree_nodes[n++] = b;
+- if (n == BTREE_FLUSH_NR)
++ btree_nodes[nr++] = b;
++ /*
++ * To avoid holding c->bucket_lock too long time,
++ * only scan for BTREE_FLUSH_NR matched btree nodes
++ * at most. If there are more btree nodes reference
++ * the oldest journal entry, try to flush them next
++ * time when btree_flush_write() is called.
++ */
++ if (nr == BTREE_FLUSH_NR)
+ break;
+ }
+ mutex_unlock(&c->bucket_lock);
+
+- for (i = 0; i < n; i++) {
++ for (i = 0; i < nr; i++) {
+ b = btree_nodes[i];
+ if (!b) {
+ pr_err("BUG: btree_nodes[%d] is NULL", i);
+@@ -497,6 +566,7 @@ static void btree_flush_write(struct cac
+ mutex_unlock(&b->write_lock);
+ }
+
++out:
+ spin_lock(&c->journal.flush_write_lock);
+ c->journal.btree_flushing = false;
+ spin_unlock(&c->journal.flush_write_lock);
--- /dev/null
+From b1b3f0622a9d52ac19a63619911823c89a4d85a4 Mon Sep 17 00:00:00 2001
+From: Jerome Brunet <jbrunet@baylibre.com>
+Date: Fri, 13 Dec 2019 11:33:04 +0100
+Subject: clk: meson: g12a: fix missing uart2 in regmap table
+
+From: Jerome Brunet <jbrunet@baylibre.com>
+
+commit b1b3f0622a9d52ac19a63619911823c89a4d85a4 upstream.
+
+UART2 peripheral is missing from the regmap fixup table of the g12a family
+clock controller. As it is, any access to this clock would Oops, which is
+not great.
+
+Add the clock to the table to fix the problem.
+
+Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller")
+Reported-by: Dmitry Shmidt <dimitrysh@google.com>
+Tested-by: Dmitry Shmidt <dimitrysh@google.com>
+Acked-by: Neil Armstrong <narmstrong@baylibre.com>
+Tested-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/meson/g12a.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/clk/meson/g12a.c
++++ b/drivers/clk/meson/g12a.c
+@@ -4692,6 +4692,7 @@ static struct clk_regmap *const g12a_clk
+ &g12a_bt656,
+ &g12a_usb1_to_ddr,
+ &g12a_mmc_pclk,
++ &g12a_uart2,
+ &g12a_vpu_intr,
+ &g12a_gic,
+ &g12a_sd_emmc_a_clk0,
--- /dev/null
+From 0bc81767c5bd9d005fae1099fb39eb3688370cb1 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Fri, 17 Jan 2020 17:43:18 +0100
+Subject: crypto: arm/chacha - fix build failured when kernel mode NEON is disabled
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+commit 0bc81767c5bd9d005fae1099fb39eb3688370cb1 upstream.
+
+When the ARM accelerated ChaCha driver is built as part of a configuration
+that has kernel mode NEON disabled, we expect the compiler to propagate
+the build time constant expression IS_ENABLED(CONFIG_KERNEL_MODE_NEON) in
+a way that eliminates all the cross-object references to the actual NEON
+routines, which allows the chacha-neon-core.o object to be omitted from
+the build entirely.
+
+Unfortunately, this fails to work as expected in some cases, and we may
+end up with a build error such as
+
+ chacha-glue.c:(.text+0xc0): undefined reference to `chacha_4block_xor_neon'
+
+caused by the fact that chacha_doneon() has not been eliminated from the
+object code, even though it will never be called in practice.
+
+Let's fix this by adding some IS_ENABLED(CONFIG_KERNEL_MODE_NEON) tests
+that are not strictly needed from a logical point of view, but should
+help the compiler infer that the NEON code paths are unreachable in
+those cases.
+
+Fixes: b36d8c09e710c71f ("crypto: arm/chacha - remove dependency on generic ...")
+Reported-by: Russell King <linux@armlinux.org.uk>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/crypto/chacha-glue.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/crypto/chacha-glue.c
++++ b/arch/arm/crypto/chacha-glue.c
+@@ -115,7 +115,7 @@ static int chacha_stream_xor(struct skci
+ if (nbytes < walk.total)
+ nbytes = round_down(nbytes, walk.stride);
+
+- if (!neon) {
++ if (!IS_ENABLED(CONFIG_KERNEL_MODE_NEON) || !neon) {
+ chacha_doarm(walk.dst.virt.addr, walk.src.virt.addr,
+ nbytes, state, ctx->nrounds);
+ state[12] += DIV_ROUND_UP(nbytes, CHACHA_BLOCK_SIZE);
+@@ -159,7 +159,7 @@ static int do_xchacha(struct skcipher_re
+
+ chacha_init_generic(state, ctx->key, req->iv);
+
+- if (!neon) {
++ if (!IS_ENABLED(CONFIG_KERNEL_MODE_NEON) || !neon) {
+ hchacha_block_arm(state, subctx.key, ctx->nrounds);
+ } else {
+ kernel_neon_begin();
--- /dev/null
+From b828f905904cd76424230c69741a4cabb0174168 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Mon, 30 Dec 2019 21:19:32 -0600
+Subject: crypto: artpec6 - return correct error code for failed setkey()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit b828f905904cd76424230c69741a4cabb0174168 upstream.
+
+->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1.
+
+Fixes: a21eb94fc4d3 ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver")
+Cc: Jesper Nilsson <jesper.nilsson@axis.com>
+Cc: Lars Persson <lars.persson@axis.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Lars Persson <lars.persson@axis.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/axis/artpec6_crypto.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/axis/artpec6_crypto.c
++++ b/drivers/crypto/axis/artpec6_crypto.c
+@@ -1251,7 +1251,7 @@ static int artpec6_crypto_aead_set_key(s
+
+ if (len != 16 && len != 24 && len != 32) {
+ crypto_aead_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
+- return -1;
++ return -EINVAL;
+ }
+
+ ctx->key_length = len;
--- /dev/null
+From b529f1983b2dcc46354f311feda92e07b6e9e2da Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Mon, 30 Dec 2019 21:19:33 -0600
+Subject: crypto: atmel-sha - fix error handling when setting hmac key
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit b529f1983b2dcc46354f311feda92e07b6e9e2da upstream.
+
+HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only
+fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated
+any error as a "bad key length" error. Fix it to correctly propagate
+the -ENOMEM error code and not set any tfm result flags.
+
+Fixes: 81d8750b2b59 ("crypto: atmel-sha - add support to hmac(shaX)")
+Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
+Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/atmel-sha.c | 7 +------
+ 1 file changed, 1 insertion(+), 6 deletions(-)
+
+--- a/drivers/crypto/atmel-sha.c
++++ b/drivers/crypto/atmel-sha.c
+@@ -1918,12 +1918,7 @@ static int atmel_sha_hmac_setkey(struct
+ {
+ struct atmel_sha_hmac_ctx *hmac = crypto_ahash_ctx(tfm);
+
+- if (atmel_sha_hmac_key_set(&hmac->hkey, key, keylen)) {
+- crypto_ahash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
+- return -EINVAL;
+- }
+-
+- return 0;
++ return atmel_sha_hmac_key_set(&hmac->hkey, key, keylen);
+ }
+
+ static int atmel_sha_hmac_init(struct ahash_request *req)
--- /dev/null
+From 53146d152510584c2034c62778a7cbca25743ce9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Horia=20Geant=C4=83?= <horia.geanta@nxp.com>
+Date: Mon, 13 Jan 2020 10:54:35 +0200
+Subject: crypto: caam/qi2 - fix typo in algorithm's driver name
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Horia Geantă <horia.geanta@nxp.com>
+
+commit 53146d152510584c2034c62778a7cbca25743ce9 upstream.
+
+Fixes: 8d818c105501 ("crypto: caam/qi2 - add DPAA2-CAAM driver")
+Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/caam/caamalg_qi2.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/caam/caamalg_qi2.c
++++ b/drivers/crypto/caam/caamalg_qi2.c
+@@ -2481,7 +2481,7 @@ static struct caam_aead_alg driver_aeads
+ .cra_name = "echainiv(authenc(hmac(sha256),"
+ "cbc(des)))",
+ .cra_driver_name = "echainiv-authenc-"
+- "hmac-sha256-cbc-desi-"
++ "hmac-sha256-cbc-des-"
+ "caam-qi2",
+ .cra_blocksize = DES_BLOCK_SIZE,
+ },
--- /dev/null
+From eb455dbd02cb1074b37872ffca30a81cb2a18eaa Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Sun, 1 Dec 2019 13:53:26 -0800
+Subject: crypto: testmgr - don't try to decrypt uninitialized buffers
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit eb455dbd02cb1074b37872ffca30a81cb2a18eaa upstream.
+
+Currently if the comparison fuzz tests encounter an encryption error
+when generating an skcipher or AEAD test vector, they will still test
+the decryption side (passing it the uninitialized ciphertext buffer)
+and expect it to fail with the same error.
+
+This is sort of broken because it's not well-defined usage of the API to
+pass an uninitialized buffer, and furthermore in the AEAD case it's
+acceptable for the decryption error to be EBADMSG (meaning "inauthentic
+input") even if the encryption error was something else like EINVAL.
+
+Fix this for skcipher by explicitly initializing the ciphertext buffer
+on error, and for AEAD by skipping the decryption test on error.
+
+Reported-by: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
+Fixes: d435e10e67be ("crypto: testmgr - fuzz skciphers against their generic implementation")
+Fixes: 40153b10d91c ("crypto: testmgr - fuzz AEADs against their generic implementation")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/testmgr.c | 20 ++++++++++++++++----
+ 1 file changed, 16 insertions(+), 4 deletions(-)
+
+--- a/crypto/testmgr.c
++++ b/crypto/testmgr.c
+@@ -2102,6 +2102,7 @@ static void generate_random_aead_testvec
+ * If the key or authentication tag size couldn't be set, no need to
+ * continue to encrypt.
+ */
++ vec->crypt_error = 0;
+ if (vec->setkey_error || vec->setauthsize_error)
+ goto done;
+
+@@ -2245,10 +2246,12 @@ static int test_aead_vs_generic_impl(con
+ req, tsgls);
+ if (err)
+ goto out;
+- err = test_aead_vec_cfg(driver, DECRYPT, &vec, vec_name, cfg,
+- req, tsgls);
+- if (err)
+- goto out;
++ if (vec.crypt_error == 0) {
++ err = test_aead_vec_cfg(driver, DECRYPT, &vec, vec_name,
++ cfg, req, tsgls);
++ if (err)
++ goto out;
++ }
+ cond_resched();
+ }
+ err = 0;
+@@ -2678,6 +2681,15 @@ static void generate_random_cipher_testv
+ skcipher_request_set_callback(req, 0, crypto_req_done, &wait);
+ skcipher_request_set_crypt(req, &src, &dst, vec->len, iv);
+ vec->crypt_error = crypto_wait_req(crypto_skcipher_encrypt(req), &wait);
++ if (vec->crypt_error != 0) {
++ /*
++ * The only acceptable error here is for an invalid length, so
++ * skcipher decryption should fail with the same error too.
++ * We'll test for this. But to keep the API usage well-defined,
++ * explicitly initialize the ciphertext buffer too.
++ */
++ memset((u8 *)vec->ctext, 0, vec->len);
++ }
+ done:
+ snprintf(name, max_namelen, "\"random: len=%u klen=%u\"",
+ vec->len, vec->klen);
--- /dev/null
+From a5b982af953bcc838cd198b0434834cc1dff14ec Mon Sep 17 00:00:00 2001
+From: Chuhong Yuan <hslester96@gmail.com>
+Date: Mon, 9 Dec 2019 16:57:11 +0800
+Subject: dmaengine: axi-dmac: add a check for devm_regmap_init_mmio
+
+From: Chuhong Yuan <hslester96@gmail.com>
+
+commit a5b982af953bcc838cd198b0434834cc1dff14ec upstream.
+
+The driver misses checking the result of devm_regmap_init_mmio().
+Add a check to fix it.
+
+Fixes: fc15be39a827 ("dmaengine: axi-dmac: add regmap support")
+Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
+Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
+Link: https://lore.kernel.org/r/20191209085711.16001-1-hslester96@gmail.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/dma-axi-dmac.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/dma/dma-axi-dmac.c
++++ b/drivers/dma/dma-axi-dmac.c
+@@ -830,6 +830,7 @@ static int axi_dmac_probe(struct platfor
+ struct dma_device *dma_dev;
+ struct axi_dmac *dmac;
+ struct resource *res;
++ struct regmap *regmap;
+ int ret;
+
+ dmac = devm_kzalloc(&pdev->dev, sizeof(*dmac), GFP_KERNEL);
+@@ -921,10 +922,17 @@ static int axi_dmac_probe(struct platfor
+
+ platform_set_drvdata(pdev, dmac);
+
+- devm_regmap_init_mmio(&pdev->dev, dmac->base, &axi_dmac_regmap_config);
++ regmap = devm_regmap_init_mmio(&pdev->dev, dmac->base,
++ &axi_dmac_regmap_config);
++ if (IS_ERR(regmap)) {
++ ret = PTR_ERR(regmap);
++ goto err_free_irq;
++ }
+
+ return 0;
+
++err_free_irq:
++ free_irq(dmac->irq, dmac);
+ err_unregister_of:
+ of_dma_controller_free(pdev->dev.of_node);
+ err_unregister_device:
--- /dev/null
+From 85fdc63fe256b595f923a69848cd99972ff446d8 Mon Sep 17 00:00:00 2001
+From: Christophe Roullier <christophe.roullier@st.com>
+Date: Fri, 22 Nov 2019 14:22:46 +0100
+Subject: drivers: watchdog: stm32_iwdg: set WDOG_HW_RUNNING at probe
+
+From: Christophe Roullier <christophe.roullier@st.com>
+
+commit 85fdc63fe256b595f923a69848cd99972ff446d8 upstream.
+
+If the watchdog hardware is already enabled during the boot process,
+when the Linux watchdog driver loads, it should start/reset the watchdog
+and tell the watchdog framework. As a result, ping can be generated from
+the watchdog framework (if CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set),
+until the userspace watchdog daemon takes over control
+
+Fixes:4332d113c66a ("watchdog: Add STM32 IWDG driver")
+
+Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Link: https://lore.kernel.org/r/20191122132246.8473-1-christophe.roullier@st.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/watchdog/stm32_iwdg.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/watchdog/stm32_iwdg.c
++++ b/drivers/watchdog/stm32_iwdg.c
+@@ -262,6 +262,24 @@ static int stm32_iwdg_probe(struct platf
+ watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT);
+ watchdog_init_timeout(wdd, 0, dev);
+
++ /*
++ * In case of CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set
++ * (Means U-Boot/bootloaders leaves the watchdog running)
++ * When we get here we should make a decision to prevent
++ * any side effects before user space daemon will take care of it.
++ * The best option, taking into consideration that there is no
++ * way to read values back from hardware, is to enforce watchdog
++ * being run with deterministic values.
++ */
++ if (IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED)) {
++ ret = stm32_iwdg_start(wdd);
++ if (ret)
++ return ret;
++
++ /* Make sure the watchdog is serviced */
++ set_bit(WDOG_HW_RUNNING, &wdd->status);
++ }
++
+ ret = devm_watchdog_register_device(dev, wdd);
+ if (ret)
+ return ret;
--- /dev/null
+From a6c4f77cb3b11f81077b53c4a38f21b92d41f21e Mon Sep 17 00:00:00 2001
+From: Beniamin Bia <beniamin.bia@analog.com>
+Date: Tue, 14 Jan 2020 15:24:01 +0200
+Subject: dt-bindings: iio: adc: ad7606: Fix wrong maxItems value
+
+From: Beniamin Bia <beniamin.bia@analog.com>
+
+commit a6c4f77cb3b11f81077b53c4a38f21b92d41f21e upstream.
+
+This patch set the correct value for oversampling maxItems. In the
+original example, appears 3 items for oversampling while the maxItems
+is set to 1, this patch fixes those issues.
+
+Fixes: 416f882c3b40 ("dt-bindings: iio: adc: Migrate AD7606 documentation to yaml")
+Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
++++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
+@@ -82,7 +82,7 @@ properties:
+ Must be the device tree identifier of the over-sampling
+ mode pins. As the line is active high, it should be marked
+ GPIO_ACTIVE_HIGH.
+- maxItems: 1
++ maxItems: 3
+
+ adi,sw-mode:
+ description:
+@@ -125,9 +125,9 @@ examples:
+ adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
+ adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+- adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH
+- &gpio 23 GPIO_ACTIVE_HIGH
+- &gpio 26 GPIO_ACTIVE_HIGH>;
++ adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
++ <&gpio 23 GPIO_ACTIVE_HIGH>,
++ <&gpio 26 GPIO_ACTIVE_HIGH>;
+ standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+ adi,sw-mode;
+ };
--- /dev/null
+From b49f8e0e7bd17b968129790e40f9e2566f4f95ec Mon Sep 17 00:00:00 2001
+From: Raul E Rangel <rrangel@chromium.org>
+Date: Thu, 21 Nov 2019 14:10:51 -0700
+Subject: i2c: cros-ec-tunnel: Fix ACPI identifier
+
+From: Raul E Rangel <rrangel@chromium.org>
+
+commit b49f8e0e7bd17b968129790e40f9e2566f4f95ec upstream.
+
+The initial patch was using the incorrect identifier.
+
+Fixes: 9af1563a5486 ("i2c: cros-ec-tunnel: Make the device acpi compatible")
+Signed-off-by: Raul E Rangel <rrangel@chromium.org>
+Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
++++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+@@ -299,7 +299,7 @@ static const struct of_device_id cros_ec
+ MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+
+ static const struct acpi_device_id cros_ec_i2c_tunnel_acpi_id[] = {
+- { "GOOG001A", 0 },
++ { "GOOG0012", 0 },
+ { }
+ };
+ MODULE_DEVICE_TABLE(acpi, cros_ec_i2c_tunnel_acpi_id);
--- /dev/null
+From 8ff2d7ca4a55dfabf12e876369835bd024eb4621 Mon Sep 17 00:00:00 2001
+From: Akshu Agrawal <akshu.agrawal@amd.com>
+Date: Thu, 21 Nov 2019 14:36:17 +0530
+Subject: i2c: cros-ec-tunnel: Fix slave device enumeration
+
+From: Akshu Agrawal <akshu.agrawal@amd.com>
+
+commit 8ff2d7ca4a55dfabf12e876369835bd024eb4621 upstream.
+
+During adding of the adapter the slave device registration
+use to fail as the acpi companion field was not populated.
+
+Fixes: 9af1563a5486 ("i2c: cros-ec-tunnel: Make the device acpi compatible")
+Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
+Acked-by: Raul E Rangel <rrangel@chromium.org>
+Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-cros-ec-tunnel.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
++++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+@@ -273,6 +273,7 @@ static int ec_i2c_probe(struct platform_
+ bus->adap.dev.parent = &pdev->dev;
+ bus->adap.dev.of_node = pdev->dev.of_node;
+ bus->adap.retries = I2C_MAX_RETRIES;
++ ACPI_COMPANION_SET(&bus->adap.dev, ACPI_COMPANION(&pdev->dev));
+
+ err = i2c_add_adapter(&bus->adap);
+ if (err)
--- /dev/null
+From 935d43ba272e0001f8ef446a3eff15d8175cb11b Mon Sep 17 00:00:00 2001
+From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
+Date: Wed, 13 Nov 2019 16:11:38 +0000
+Subject: iommu/arm-smmu-v3: Populate VMID field for CMDQ_OP_TLBI_NH_VA
+
+From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
+
+commit 935d43ba272e0001f8ef446a3eff15d8175cb11b upstream.
+
+CMDQ_OP_TLBI_NH_VA requires VMID and this was missing since
+commit 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask
+for CMD_TLBI_S2_IPA"). Add it back.
+
+Fixes: 1c27df1c0a82 ("iommu/arm-smmu: Use correct address mask for CMD_TLBI_S2_IPA")
+Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/arm-smmu-v3.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/iommu/arm-smmu-v3.c
++++ b/drivers/iommu/arm-smmu-v3.c
+@@ -856,6 +856,7 @@ static int arm_smmu_cmdq_build_cmd(u64 *
+ cmd[1] |= FIELD_PREP(CMDQ_CFGI_1_RANGE, 31);
+ break;
+ case CMDQ_OP_TLBI_NH_VA:
++ cmd[0] |= FIELD_PREP(CMDQ_TLBI_0_VMID, ent->tlbi.vmid);
+ cmd[0] |= FIELD_PREP(CMDQ_TLBI_0_ASID, ent->tlbi.asid);
+ cmd[1] |= FIELD_PREP(CMDQ_TLBI_1_LEAF, ent->tlbi.leaf);
+ cmd[1] |= ent->tlbi.addr & CMDQ_TLBI_1_VA_MASK;
--- /dev/null
+From cf2d23e0bac9f6b5cd1cba8898f5f05ead40e530 Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gshan@redhat.com>
+Date: Tue, 21 Jan 2020 16:56:59 +1100
+Subject: KVM: arm/arm64: Fix young bit from mmu notifier
+
+From: Gavin Shan <gshan@redhat.com>
+
+commit cf2d23e0bac9f6b5cd1cba8898f5f05ead40e530 upstream.
+
+kvm_test_age_hva() is called upon mmu_notifier_test_young(), but wrong
+address range has been passed to handle_hva_to_gpa(). With the wrong
+address range, no young bits will be checked in handle_hva_to_gpa().
+It means zero is always returned from mmu_notifier_test_young().
+
+This fixes the issue by passing correct address range to the underly
+function handle_hva_to_gpa(), so that the hardware young (access) bit
+will be visited.
+
+Fixes: 35307b9a5f7e ("arm/arm64: KVM: Implement Stage-2 page aging")
+Signed-off-by: Gavin Shan <gshan@redhat.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200121055659.19560-1-gshan@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/mmu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/virt/kvm/arm/mmu.c
++++ b/virt/kvm/arm/mmu.c
+@@ -2147,7 +2147,8 @@ int kvm_test_age_hva(struct kvm *kvm, un
+ if (!kvm->arch.pgd)
+ return 0;
+ trace_kvm_test_age_hva(hva);
+- return handle_hva_to_gpa(kvm, hva, hva, kvm_test_age_hva_handler, NULL);
++ return handle_hva_to_gpa(kvm, hva, hva + PAGE_SIZE,
++ kvm_test_age_hva_handler, NULL);
+ }
+
+ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu)
--- /dev/null
+From 8c58be34494b7f1b2adb446e2d8beeb90e5de65b Mon Sep 17 00:00:00 2001
+From: Eric Auger <eric.auger@redhat.com>
+Date: Fri, 13 Dec 2019 10:42:37 +0100
+Subject: KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections
+
+From: Eric Auger <eric.auger@redhat.com>
+
+commit 8c58be34494b7f1b2adb446e2d8beeb90e5de65b upstream.
+
+Saving/restoring an unmapped collection is a valid scenario. For
+example this happens if a MAPTI command was sent, featuring an
+unmapped collection. At the moment the CTE fails to be restored.
+Only compare against the number of online vcpus if the rdist
+base is set.
+
+Fixes: ea1ad53e1e31a ("KVM: arm64: vgic-its: Collection table save/restore")
+Signed-off-by: Eric Auger <eric.auger@redhat.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
+Link: https://lore.kernel.org/r/20191213094237.19627-1-eric.auger@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/vgic/vgic-its.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/virt/kvm/arm/vgic/vgic-its.c
++++ b/virt/kvm/arm/vgic/vgic-its.c
+@@ -2475,7 +2475,8 @@ static int vgic_its_restore_cte(struct v
+ target_addr = (u32)(val >> KVM_ITS_CTE_RDBASE_SHIFT);
+ coll_id = val & KVM_ITS_CTE_ICID_MASK;
+
+- if (target_addr >= atomic_read(&kvm->online_vcpus))
++ if (target_addr != COLLECTION_NOT_MAPPED &&
++ target_addr >= atomic_read(&kvm->online_vcpus))
+ return -EINVAL;
+
+ collection = find_collection(its, coll_id);
--- /dev/null
+From 018f22f95e8a6c3e27188b7317ef2c70a34cb2cd Mon Sep 17 00:00:00 2001
+From: James Morse <james.morse@arm.com>
+Date: Tue, 21 Jan 2020 12:33:55 +0000
+Subject: KVM: arm: Fix DFSR setting for non-LPAE aarch32 guests
+
+From: James Morse <james.morse@arm.com>
+
+commit 018f22f95e8a6c3e27188b7317ef2c70a34cb2cd upstream.
+
+Beata reports that KVM_SET_VCPU_EVENTS doesn't inject the expected
+exception to a non-LPAE aarch32 guest.
+
+The host intends to inject DFSR.FS=0x14 "IMPLEMENTATION DEFINED fault
+(Lockdown fault)", but the guest receives DFSR.FS=0x04 "Fault on
+instruction cache maintenance". This fault is hooked by
+do_translation_fault() since ARMv6, which goes on to silently 'handle'
+the exception, and restart the faulting instruction.
+
+It turns out, when TTBCR.EAE is clear DFSR is split, and FS[4] has
+to shuffle up to DFSR[10].
+
+As KVM only does this in one place, fix up the static values. We
+now get the expected:
+| Unhandled fault: lock abort (0x404) at 0x9c800f00
+
+Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection")
+Reported-by: Beata Michalska <beata.michalska@linaro.org>
+Signed-off-by: James Morse <james.morse@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200121123356.203000-2-james.morse@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/aarch32.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/virt/kvm/arm/aarch32.c
++++ b/virt/kvm/arm/aarch32.c
+@@ -181,10 +181,12 @@ static void inject_abt32(struct kvm_vcpu
+
+ /* Give the guest an IMPLEMENTATION DEFINED exception */
+ is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
+- if (is_lpae)
++ if (is_lpae) {
+ *fsr = 1 << 9 | 0x34;
+- else
+- *fsr = 0x14;
++ } else {
++ /* Surprise! DFSR's FS[4] lives in bit 10 */
++ *fsr = BIT(10) | 0x4; /* 0x14 */
++ }
+ }
+
+ void kvm_inject_dabt32(struct kvm_vcpu *vcpu, unsigned long addr)
--- /dev/null
+From 21aecdbd7f3ab02c9b82597dc733ee759fb8b274 Mon Sep 17 00:00:00 2001
+From: James Morse <james.morse@arm.com>
+Date: Tue, 21 Jan 2020 12:33:56 +0000
+Subject: KVM: arm: Make inject_abt32() inject an external abort instead
+
+From: James Morse <james.morse@arm.com>
+
+commit 21aecdbd7f3ab02c9b82597dc733ee759fb8b274 upstream.
+
+KVM's inject_abt64() injects an external-abort into an aarch64 guest.
+The KVM_CAP_ARM_INJECT_EXT_DABT is intended to do exactly this, but
+for an aarch32 guest inject_abt32() injects an implementation-defined
+exception, 'Lockdown fault'.
+
+Change this to external abort. For non-LPAE we now get the documented:
+| Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00
+and for LPAE:
+| Unhandled fault: synchronous external abort (0x210) at 0x9c800f00
+
+Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection")
+Reported-by: Beata Michalska <beata.michalska@linaro.org>
+Signed-off-by: James Morse <james.morse@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200121123356.203000-3-james.morse@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/aarch32.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/virt/kvm/arm/aarch32.c
++++ b/virt/kvm/arm/aarch32.c
+@@ -15,6 +15,10 @@
+ #include <asm/kvm_emulate.h>
+ #include <asm/kvm_hyp.h>
+
++#define DFSR_FSC_EXTABT_LPAE 0x10
++#define DFSR_FSC_EXTABT_nLPAE 0x08
++#define DFSR_LPAE BIT(9)
++
+ /*
+ * Table taken from ARMv8 ARM DDI0487B-B, table G1-10.
+ */
+@@ -182,10 +186,10 @@ static void inject_abt32(struct kvm_vcpu
+ /* Give the guest an IMPLEMENTATION DEFINED exception */
+ is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
+ if (is_lpae) {
+- *fsr = 1 << 9 | 0x34;
++ *fsr = DFSR_LPAE | DFSR_FSC_EXTABT_LPAE;
+ } else {
+- /* Surprise! DFSR's FS[4] lives in bit 10 */
+- *fsr = BIT(10) | 0x4; /* 0x14 */
++ /* no need to shuffle FS[4] into DFSR[10] as its 0 */
++ *fsr = DFSR_FSC_EXTABT_nLPAE;
+ }
+ }
+
--- /dev/null
+From 3837407c1aa1101ed5e214c7d6041e7a23335c6e Mon Sep 17 00:00:00 2001
+From: Eric Auger <eric.auger@redhat.com>
+Date: Fri, 24 Jan 2020 15:25:32 +0100
+Subject: KVM: arm64: pmu: Don't increment SW_INCR if PMCR.E is unset
+
+From: Eric Auger <eric.auger@redhat.com>
+
+commit 3837407c1aa1101ed5e214c7d6041e7a23335c6e upstream.
+
+The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1
+if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR.
+
+For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to
+be set for the corresponding event counter but we also need
+the PMCR.E bit to be set.
+
+Fixes: 7a0adc7064b8 ("arm64: KVM: Add access handler for PMSWINC register")
+Signed-off-by: Eric Auger <eric.auger@redhat.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Andrew Murray <andrew.murray@arm.com>
+Acked-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200124142535.29386-2-eric.auger@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/pmu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/virt/kvm/arm/pmu.c
++++ b/virt/kvm/arm/pmu.c
+@@ -486,6 +486,9 @@ void kvm_pmu_software_increment(struct k
+ if (val == 0)
+ return;
+
++ if (!(__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
++ return;
++
+ enable = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+ for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
+ if (!(val & BIT(i)))
--- /dev/null
+From aa76829171e98bd75a0cc00b6248eca269ac7f4f Mon Sep 17 00:00:00 2001
+From: Eric Auger <eric.auger@redhat.com>
+Date: Fri, 24 Jan 2020 15:25:34 +0100
+Subject: KVM: arm64: pmu: Fix chained SW_INCR counters
+
+From: Eric Auger <eric.auger@redhat.com>
+
+commit aa76829171e98bd75a0cc00b6248eca269ac7f4f upstream.
+
+At the moment a SW_INCR counter always overflows on 32-bit
+boundary, independently on whether the n+1th counter is
+programmed as CHAIN.
+
+Check whether the SW_INCR counter is a 64b counter and if so,
+implement the 64b logic.
+
+Fixes: 80f393a23be6 ("KVM: arm/arm64: Support chained PMU counters")
+Signed-off-by: Eric Auger <eric.auger@redhat.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20200124142535.29386-4-eric.auger@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/pmu.c | 43 ++++++++++++++++++++++++++++++-------------
+ 1 file changed, 30 insertions(+), 13 deletions(-)
+
+--- a/virt/kvm/arm/pmu.c
++++ b/virt/kvm/arm/pmu.c
+@@ -480,28 +480,45 @@ static void kvm_pmu_perf_overflow(struct
+ */
+ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+ {
++ struct kvm_pmu *pmu = &vcpu->arch.pmu;
+ int i;
+- u64 type, enable, reg;
+-
+- if (val == 0)
+- return;
+
+ if (!(__vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
+ return;
+
+- enable = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
++ /* Weed out disabled counters */
++ val &= __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
++
+ for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
++ u64 type, reg;
++
+ if (!(val & BIT(i)))
+ continue;
+- type = __vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+- & ARMV8_PMU_EVTYPE_EVENT;
+- if ((type == ARMV8_PMUV3_PERFCTR_SW_INCR)
+- && (enable & BIT(i))) {
+- reg = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
++
++ /* PMSWINC only applies to ... SW_INC! */
++ type = __vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i);
++ type &= ARMV8_PMU_EVTYPE_EVENT;
++ if (type != ARMV8_PMUV3_PERFCTR_SW_INCR)
++ continue;
++
++ /* increment this even SW_INC counter */
++ reg = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
++ reg = lower_32_bits(reg);
++ __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
++
++ if (reg) /* no overflow on the low part */
++ continue;
++
++ if (kvm_pmu_pmc_is_chained(&pmu->pmc[i])) {
++ /* increment the high counter */
++ reg = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i + 1) + 1;
+ reg = lower_32_bits(reg);
+- __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+- if (!reg)
+- __vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= BIT(i);
++ __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i + 1) = reg;
++ if (!reg) /* mark overflow on the high counter */
++ __vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= BIT(i + 1);
++ } else {
++ /* mark overflow on low counter */
++ __vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= BIT(i);
+ }
+ }
+ }
--- /dev/null
+From 4a267aa707953a9a73d1f5dc7f894dd9024a92be Mon Sep 17 00:00:00 2001
+From: Alexandru Elisei <alexandru.elisei@arm.com>
+Date: Mon, 27 Jan 2020 10:36:52 +0000
+Subject: KVM: arm64: Treat emulated TVAL TimerValue as a signed 32-bit integer
+
+From: Alexandru Elisei <alexandru.elisei@arm.com>
+
+commit 4a267aa707953a9a73d1f5dc7f894dd9024a92be upstream.
+
+According to the ARM ARM, registers CNT{P,V}_TVAL_EL0 have bits [63:32]
+RES0 [1]. When reading the register, the value is truncated to the least
+significant 32 bits [2], and on writes, TimerValue is treated as a signed
+32-bit integer [1, 2].
+
+When the guest behaves correctly and writes 32-bit values, treating TVAL
+as an unsigned 64 bit register works as expected. However, things start
+to break down when the guest writes larger values, because
+(u64)0x1_ffff_ffff = 8589934591. but (s32)0x1_ffff_ffff = -1, and the
+former will cause the timer interrupt to be asserted in the future, but
+the latter will cause it to be asserted now. Let's treat TVAL as a
+signed 32-bit register on writes, to match the behaviour described in
+the architecture, and the behaviour experimentally exhibited by the
+virtual timer on a non-vhe host.
+
+[1] Arm DDI 0487E.a, section D13.8.18
+[2] Arm DDI 0487E.a, section D11.2.4
+
+Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
+[maz: replaced the read-side mask with lower_32_bits]
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Fixes: 8fa761624871 ("KVM: arm/arm64: arch_timer: Fix CNTP_TVAL calculation")
+Link: https://lore.kernel.org/r/20200127103652.2326-1-alexandru.elisei@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/arch_timer.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/virt/kvm/arm/arch_timer.c
++++ b/virt/kvm/arm/arch_timer.c
+@@ -805,6 +805,7 @@ static u64 kvm_arm_timer_read(struct kvm
+ switch (treg) {
+ case TIMER_REG_TVAL:
+ val = timer->cnt_cval - kvm_phys_timer_read() + timer->cntvoff;
++ val &= lower_32_bits(val);
+ break;
+
+ case TIMER_REG_CTL:
+@@ -850,7 +851,7 @@ static void kvm_arm_timer_write(struct k
+ {
+ switch (treg) {
+ case TIMER_REG_TVAL:
+- timer->cnt_cval = kvm_phys_timer_read() - timer->cntvoff + val;
++ timer->cnt_cval = kvm_phys_timer_read() - timer->cntvoff + (s32)val;
+ break;
+
+ case TIMER_REG_CTL:
--- /dev/null
+From 0d962e061abcf1b9105f88fb850158b5887fbca3 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Oct 2019 15:25:22 +0200
+Subject: media: i2c: adv748x: Fix unsafe macros
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 0d962e061abcf1b9105f88fb850158b5887fbca3 upstream.
+
+Enclose multiple macro parameters in parentheses in order to
+make such macros safer and fix the Clang warning below:
+
+drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:'
+has lower precedence than '|'; '|' will be evaluated first
+[-Wbitwise-conditional-parentheses]
+
+ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable
+? ctrl->val - 1 : 0);
+
+Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/i2c/adv748x/adv748x.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/i2c/adv748x/adv748x.h
++++ b/drivers/media/i2c/adv748x/adv748x.h
+@@ -394,10 +394,10 @@ int adv748x_write_block(struct adv748x_s
+
+ #define io_read(s, r) adv748x_read(s, ADV748X_PAGE_IO, r)
+ #define io_write(s, r, v) adv748x_write(s, ADV748X_PAGE_IO, r, v)
+-#define io_clrset(s, r, m, v) io_write(s, r, (io_read(s, r) & ~m) | v)
++#define io_clrset(s, r, m, v) io_write(s, r, (io_read(s, r) & ~(m)) | (v))
+
+ #define hdmi_read(s, r) adv748x_read(s, ADV748X_PAGE_HDMI, r)
+-#define hdmi_read16(s, r, m) (((hdmi_read(s, r) << 8) | hdmi_read(s, r+1)) & m)
++#define hdmi_read16(s, r, m) (((hdmi_read(s, r) << 8) | hdmi_read(s, (r)+1)) & (m))
+ #define hdmi_write(s, r, v) adv748x_write(s, ADV748X_PAGE_HDMI, r, v)
+
+ #define repeater_read(s, r) adv748x_read(s, ADV748X_PAGE_REPEATER, r)
+@@ -405,11 +405,11 @@ int adv748x_write_block(struct adv748x_s
+
+ #define sdp_read(s, r) adv748x_read(s, ADV748X_PAGE_SDP, r)
+ #define sdp_write(s, r, v) adv748x_write(s, ADV748X_PAGE_SDP, r, v)
+-#define sdp_clrset(s, r, m, v) sdp_write(s, r, (sdp_read(s, r) & ~m) | v)
++#define sdp_clrset(s, r, m, v) sdp_write(s, r, (sdp_read(s, r) & ~(m)) | (v))
+
+ #define cp_read(s, r) adv748x_read(s, ADV748X_PAGE_CP, r)
+ #define cp_write(s, r, v) adv748x_write(s, ADV748X_PAGE_CP, r, v)
+-#define cp_clrset(s, r, m, v) cp_write(s, r, (cp_read(s, r) & ~m) | v)
++#define cp_clrset(s, r, m, v) cp_write(s, r, (cp_read(s, r) & ~(m)) | (v))
+
+ #define tx_read(t, r) adv748x_read(t->state, t->page, r)
+ #define tx_write(t, r, v) adv748x_write(t->state, t->page, r, v)
--- /dev/null
+From cb7a374a5e7a5af3f8c839f74439193add6d0589 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Date: Fri, 3 Jan 2020 12:41:56 +0100
+Subject: mfd: max77650: Select REGMAP_IRQ in Kconfig
+
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+commit cb7a374a5e7a5af3f8c839f74439193add6d0589 upstream.
+
+MAX77650 MFD driver uses regmap_irq API but doesn't select the required
+REGMAP_IRQ option in Kconfig. This can cause the following build error
+if regmap irq is not enabled implicitly by someone else:
+
+ ld: drivers/mfd/max77650.o: in function `max77650_i2c_probe':
+ max77650.c:(.text+0xcb): undefined reference to `devm_regmap_add_irq_chip'
+ ld: max77650.c:(.text+0xdb): undefined reference to `regmap_irq_get_domain'
+ make: *** [Makefile:1079: vmlinux] Error 1
+
+Fix it by adding the missing option.
+
+Fixes: d0f60334500b ("mfd: Add new driver for MAX77650 PMIC")
+Reported-by: Paul Gazzillo <paul@pgazz.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mfd/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mfd/Kconfig
++++ b/drivers/mfd/Kconfig
+@@ -758,6 +758,7 @@ config MFD_MAX77650
+ depends on OF || COMPILE_TEST
+ select MFD_CORE
+ select REGMAP_I2C
++ select REGMAP_IRQ
+ help
+ Say Y here to add support for Maxim Semiconductor MAX77650 and
+ MAX77651 Power Management ICs. This is the core multifunction
--- /dev/null
+From 0e7ca83e82d021c928dadf4c13c137d57337540d Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Mon, 9 Dec 2019 14:44:23 -0700
+Subject: mtd: onenand_base: Adjust indentation in onenand_read_ops_nolock
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+commit 0e7ca83e82d021c928dadf4c13c137d57337540d upstream.
+
+Clang warns:
+
+../drivers/mtd/nand/onenand/onenand_base.c:1269:3: warning: misleading
+indentation; statement is not part of the previous 'if'
+[-Wmisleading-indentation]
+ while (!ret) {
+ ^
+../drivers/mtd/nand/onenand/onenand_base.c:1266:2: note: previous
+statement is here
+ if (column + thislen > writesize)
+ ^
+1 warning generated.
+
+This warning occurs because there is a space before the tab of the while
+loop. There are spaces at the beginning of a lot of the lines in this
+block, remove them so that the indentation is consistent with the Linux
+kernel coding style and clang no longer warns.
+
+Fixes: a8de85d55700 ("[MTD] OneNAND: Implement read-while-load")
+Link: https://github.com/ClangBuiltLinux/linux/issues/794
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/nand/onenand/onenand_base.c | 82 ++++++++++++++++----------------
+ 1 file changed, 41 insertions(+), 41 deletions(-)
+
+--- a/drivers/mtd/nand/onenand/onenand_base.c
++++ b/drivers/mtd/nand/onenand/onenand_base.c
+@@ -1248,44 +1248,44 @@ static int onenand_read_ops_nolock(struc
+
+ stats = mtd->ecc_stats;
+
+- /* Read-while-load method */
++ /* Read-while-load method */
+
+- /* Do first load to bufferRAM */
+- if (read < len) {
+- if (!onenand_check_bufferram(mtd, from)) {
++ /* Do first load to bufferRAM */
++ if (read < len) {
++ if (!onenand_check_bufferram(mtd, from)) {
+ this->command(mtd, ONENAND_CMD_READ, from, writesize);
+- ret = this->wait(mtd, FL_READING);
+- onenand_update_bufferram(mtd, from, !ret);
++ ret = this->wait(mtd, FL_READING);
++ onenand_update_bufferram(mtd, from, !ret);
+ if (mtd_is_eccerr(ret))
+ ret = 0;
+- }
+- }
++ }
++ }
+
+ thislen = min_t(int, writesize, len - read);
+ column = from & (writesize - 1);
+ if (column + thislen > writesize)
+ thislen = writesize - column;
+
+- while (!ret) {
+- /* If there is more to load then start next load */
+- from += thislen;
+- if (read + thislen < len) {
++ while (!ret) {
++ /* If there is more to load then start next load */
++ from += thislen;
++ if (read + thislen < len) {
+ this->command(mtd, ONENAND_CMD_READ, from, writesize);
+- /*
+- * Chip boundary handling in DDP
+- * Now we issued chip 1 read and pointed chip 1
++ /*
++ * Chip boundary handling in DDP
++ * Now we issued chip 1 read and pointed chip 1
+ * bufferram so we have to point chip 0 bufferram.
+- */
+- if (ONENAND_IS_DDP(this) &&
+- unlikely(from == (this->chipsize >> 1))) {
+- this->write_word(ONENAND_DDP_CHIP0, this->base + ONENAND_REG_START_ADDRESS2);
+- boundary = 1;
+- } else
+- boundary = 0;
+- ONENAND_SET_PREV_BUFFERRAM(this);
+- }
+- /* While load is going, read from last bufferRAM */
+- this->read_bufferram(mtd, ONENAND_DATARAM, buf, column, thislen);
++ */
++ if (ONENAND_IS_DDP(this) &&
++ unlikely(from == (this->chipsize >> 1))) {
++ this->write_word(ONENAND_DDP_CHIP0, this->base + ONENAND_REG_START_ADDRESS2);
++ boundary = 1;
++ } else
++ boundary = 0;
++ ONENAND_SET_PREV_BUFFERRAM(this);
++ }
++ /* While load is going, read from last bufferRAM */
++ this->read_bufferram(mtd, ONENAND_DATARAM, buf, column, thislen);
+
+ /* Read oob area if needed */
+ if (oobbuf) {
+@@ -1301,24 +1301,24 @@ static int onenand_read_ops_nolock(struc
+ oobcolumn = 0;
+ }
+
+- /* See if we are done */
+- read += thislen;
+- if (read == len)
+- break;
+- /* Set up for next read from bufferRAM */
+- if (unlikely(boundary))
+- this->write_word(ONENAND_DDP_CHIP1, this->base + ONENAND_REG_START_ADDRESS2);
+- ONENAND_SET_NEXT_BUFFERRAM(this);
+- buf += thislen;
++ /* See if we are done */
++ read += thislen;
++ if (read == len)
++ break;
++ /* Set up for next read from bufferRAM */
++ if (unlikely(boundary))
++ this->write_word(ONENAND_DDP_CHIP1, this->base + ONENAND_REG_START_ADDRESS2);
++ ONENAND_SET_NEXT_BUFFERRAM(this);
++ buf += thislen;
+ thislen = min_t(int, writesize, len - read);
+- column = 0;
+- cond_resched();
+- /* Now wait for load */
+- ret = this->wait(mtd, FL_READING);
+- onenand_update_bufferram(mtd, from, !ret);
++ column = 0;
++ cond_resched();
++ /* Now wait for load */
++ ret = this->wait(mtd, FL_READING);
++ onenand_update_bufferram(mtd, from, !ret);
+ if (mtd_is_eccerr(ret))
+ ret = 0;
+- }
++ }
+
+ /*
+ * Return success, if no ECC failures, else -EBADMSG
--- /dev/null
+From f33113b542219448fa02d77ca1c6f4265bd7f130 Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Mon, 30 Dec 2019 11:29:45 +0800
+Subject: mtd: sharpslpart: Fix unsigned comparison to zero
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+commit f33113b542219448fa02d77ca1c6f4265bd7f130 upstream.
+
+The unsigned variable log_num is being assigned a return value
+from the call to sharpsl_nand_get_logical_num that can return
+-EINVAL.
+
+Detected using Coccinelle:
+./drivers/mtd/parsers/sharpslpart.c:207:6-13: WARNING: Unsigned expression compared with zero: log_num > 0
+
+Fixes: 8a4580e4d298 ("mtd: sharpslpart: Add sharpslpart partition parser")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/parsers/sharpslpart.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/parsers/sharpslpart.c
++++ b/drivers/mtd/parsers/sharpslpart.c
+@@ -165,10 +165,10 @@ static int sharpsl_nand_get_logical_num(
+
+ static int sharpsl_nand_init_ftl(struct mtd_info *mtd, struct sharpsl_ftl *ftl)
+ {
+- unsigned int block_num, log_num, phymax;
++ unsigned int block_num, phymax;
++ int i, ret, log_num;
+ loff_t block_adr;
+ u8 *oob;
+- int i, ret;
+
+ oob = kzalloc(mtd->oobsize, GFP_KERNEL);
+ if (!oob)
--- /dev/null
+From 539d8bde72c22d760013bf81436d6bb94eb67aed Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Thu, 24 Oct 2019 17:33:42 +0300
+Subject: pinctrl: baytrail: Allocate IRQ chip dynamic
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 539d8bde72c22d760013bf81436d6bb94eb67aed upstream.
+
+Keeping the IRQ chip definition static shares it with multiple instances
+of the GPIO chip in the system. This is bad and now we get this warning
+from GPIO library:
+
+"detected irqchip that is shared with multiple gpiochips: please fix the driver."
+
+Hence, move the IRQ chip definition from being driver static into the struct
+intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance.
+
+Fixes: 9f573b98ca50 ("pinctrl: baytrail: Update irq chip operations")
+Depends-on: ca8a958e2acb ("pinctrl: baytrail: Pass irqchip when adding gpiochip")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/intel/pinctrl-baytrail.c | 19 +++++++++----------
+ 1 file changed, 9 insertions(+), 10 deletions(-)
+
+--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
++++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
+@@ -107,6 +107,7 @@ struct byt_gpio_pin_context {
+
+ struct byt_gpio {
+ struct gpio_chip chip;
++ struct irq_chip irqchip;
+ struct platform_device *pdev;
+ struct pinctrl_dev *pctl_dev;
+ struct pinctrl_desc pctl_desc;
+@@ -1395,15 +1396,6 @@ static int byt_irq_type(struct irq_data
+ return 0;
+ }
+
+-static struct irq_chip byt_irqchip = {
+- .name = "BYT-GPIO",
+- .irq_ack = byt_irq_ack,
+- .irq_mask = byt_irq_mask,
+- .irq_unmask = byt_irq_unmask,
+- .irq_set_type = byt_irq_type,
+- .flags = IRQCHIP_SKIP_SET_WAKE,
+-};
+-
+ static void byt_gpio_irq_handler(struct irq_desc *desc)
+ {
+ struct irq_data *data = irq_desc_get_irq_data(desc);
+@@ -1551,8 +1543,15 @@ static int byt_gpio_probe(struct byt_gpi
+ if (irq_rc && irq_rc->start) {
+ struct gpio_irq_chip *girq;
+
++ vg->irqchip.name = "BYT-GPIO",
++ vg->irqchip.irq_ack = byt_irq_ack,
++ vg->irqchip.irq_mask = byt_irq_mask,
++ vg->irqchip.irq_unmask = byt_irq_unmask,
++ vg->irqchip.irq_set_type = byt_irq_type,
++ vg->irqchip.flags = IRQCHIP_SKIP_SET_WAKE,
++
+ girq = &gc->irq;
+- girq->chip = &byt_irqchip;
++ girq->chip = &vg->irqchip;
+ girq->init_hw = byt_gpio_irq_init_hw;
+ girq->parent_handler = byt_gpio_irq_handler;
+ girq->num_parents = 1;
--- /dev/null
+From 1d44616e7549d0154c1224a3eee3c407029294dc Mon Sep 17 00:00:00 2001
+From: Stephen Boyd <swboyd@chromium.org>
+Date: Tue, 21 Jan 2020 10:09:50 -0800
+Subject: pinctrl: qcom: Don't lock around irq_set_irq_wake()
+
+From: Stephen Boyd <swboyd@chromium.org>
+
+commit 1d44616e7549d0154c1224a3eee3c407029294dc upstream.
+
+We don't need to hold the local pinctrl lock here to set irq wake on the
+summary irq line. Doing so only leads to lockdep warnings instead of
+protecting us from anything. Remove the locking.
+
+ WARNING: possible circular locking dependency detected
+ 5.4.11 #2 Tainted: G W
+ ------------------------------------------------------
+ cat/3083 is trying to acquire lock:
+ ffffff81f4fa58c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
+
+ but task is already holding lock:
+ ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #1 (&pctrl->lock){-.-.}:
+ _raw_spin_lock_irqsave+0x64/0x80
+ msm_gpio_irq_ack+0x68/0xf4
+ __irq_do_set_handler+0xe0/0x180
+ __irq_set_handler+0x60/0x9c
+ irq_domain_set_info+0x90/0xb4
+ gpiochip_hierarchy_irq_domain_alloc+0x110/0x200
+ __irq_domain_alloc_irqs+0x130/0x29c
+ irq_create_fwspec_mapping+0x1f0/0x300
+ irq_create_of_mapping+0x70/0x98
+ of_irq_get+0xa4/0xd4
+ spi_drv_probe+0x4c/0xb0
+ really_probe+0x138/0x3f0
+ driver_probe_device+0x70/0x140
+ __device_attach_driver+0x9c/0x110
+ bus_for_each_drv+0x88/0xd0
+ __device_attach+0xb0/0x160
+ device_initial_probe+0x20/0x2c
+ bus_probe_device+0x34/0x94
+ device_add+0x35c/0x3f0
+ spi_add_device+0xbc/0x194
+ of_register_spi_devices+0x2c8/0x408
+ spi_register_controller+0x57c/0x6fc
+ spi_geni_probe+0x260/0x328
+ platform_drv_probe+0x90/0xb0
+ really_probe+0x138/0x3f0
+ driver_probe_device+0x70/0x140
+ device_driver_attach+0x4c/0x6c
+ __driver_attach+0xcc/0x154
+ bus_for_each_dev+0x84/0xcc
+ driver_attach+0x2c/0x38
+ bus_add_driver+0x108/0x1fc
+ driver_register+0x64/0xf8
+ __platform_driver_register+0x4c/0x58
+ spi_geni_driver_init+0x1c/0x24
+ do_one_initcall+0x1a4/0x3e8
+ do_initcall_level+0xb4/0xcc
+ do_basic_setup+0x30/0x48
+ kernel_init_freeable+0x124/0x1a8
+ kernel_init+0x14/0x100
+ ret_from_fork+0x10/0x18
+
+ -> #0 (&irq_desc_lock_class){-.-.}:
+ __lock_acquire+0xeb4/0x2388
+ lock_acquire+0x1cc/0x210
+ _raw_spin_lock_irqsave+0x64/0x80
+ __irq_get_desc_lock+0x64/0x94
+ irq_set_irq_wake+0x40/0x144
+ msm_gpio_irq_set_wake+0x5c/0x7c
+ set_irq_wake_real+0x40/0x5c
+ irq_set_irq_wake+0x70/0x144
+ cros_ec_rtc_suspend+0x38/0x4c
+ platform_pm_suspend+0x34/0x60
+ dpm_run_callback+0x64/0xcc
+ __device_suspend+0x310/0x41c
+ dpm_suspend+0xf8/0x298
+ dpm_suspend_start+0x84/0xb4
+ suspend_devices_and_enter+0xbc/0x620
+ pm_suspend+0x210/0x348
+ state_store+0xb0/0x108
+ kobj_attr_store+0x14/0x24
+ sysfs_kf_write+0x4c/0x64
+ kernfs_fop_write+0x15c/0x1fc
+ __vfs_write+0x54/0x18c
+ vfs_write+0xe4/0x1a4
+ ksys_write+0x7c/0xe4
+ __arm64_sys_write+0x20/0x2c
+ el0_svc_common+0xa8/0x160
+ el0_svc_handler+0x7c/0x98
+ el0_svc+0x8/0xc
+
+ other info that might help us debug this:
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(&pctrl->lock);
+ lock(&irq_desc_lock_class);
+ lock(&pctrl->lock);
+ lock(&irq_desc_lock_class);
+
+ *** DEADLOCK ***
+
+ 7 locks held by cat/3083:
+ #0: ffffff81f06d1420 (sb_writers#7){.+.+}, at: vfs_write+0xd0/0x1a4
+ #1: ffffff81c8935680 (&of->mutex){+.+.}, at: kernfs_fop_write+0x12c/0x1fc
+ #2: ffffff81f4c322f0 (kn->count#337){.+.+}, at: kernfs_fop_write+0x134/0x1fc
+ #3: ffffffe89a641d60 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x348
+ #4: ffffff81f190e970 (&dev->mutex){....}, at: __device_suspend+0x168/0x41c
+ #5: ffffff81f183d8c0 (lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
+ #6: ffffff81f4880c18 (&pctrl->lock){-.-.}, at: msm_gpio_irq_set_wake+0x48/0x7c
+
+ stack backtrace:
+ CPU: 4 PID: 3083 Comm: cat Tainted: G W 5.4.11 #2
+ Hardware name: Google Cheza (rev3+) (DT)
+ Call trace:
+ dump_backtrace+0x0/0x174
+ show_stack+0x20/0x2c
+ dump_stack+0xc8/0x124
+ print_circular_bug+0x2ac/0x2c4
+ check_noncircular+0x1a0/0x1a8
+ __lock_acquire+0xeb4/0x2388
+ lock_acquire+0x1cc/0x210
+ _raw_spin_lock_irqsave+0x64/0x80
+ __irq_get_desc_lock+0x64/0x94
+ irq_set_irq_wake+0x40/0x144
+ msm_gpio_irq_set_wake+0x5c/0x7c
+ set_irq_wake_real+0x40/0x5c
+ irq_set_irq_wake+0x70/0x144
+ cros_ec_rtc_suspend+0x38/0x4c
+ platform_pm_suspend+0x34/0x60
+ dpm_run_callback+0x64/0xcc
+ __device_suspend+0x310/0x41c
+ dpm_suspend+0xf8/0x298
+ dpm_suspend_start+0x84/0xb4
+ suspend_devices_and_enter+0xbc/0x620
+ pm_suspend+0x210/0x348
+ state_store+0xb0/0x108
+ kobj_attr_store+0x14/0x24
+ sysfs_kf_write+0x4c/0x64
+ kernfs_fop_write+0x15c/0x1fc
+ __vfs_write+0x54/0x18c
+ vfs_write+0xe4/0x1a4
+ ksys_write+0x7c/0xe4
+ __arm64_sys_write+0x20/0x2c
+ el0_svc_common+0xa8/0x160
+ el0_svc_handler+0x7c/0x98
+ el0_svc+0x8/0xc
+
+Fixes: 6aced33f4974 ("pinctrl: msm: drop wake_irqs bitmap")
+Cc: Douglas Anderson <dianders@chromium.org>
+Cc: Brian Masney <masneyb@onstation.org>
+Cc: Lina Iyer <ilina@codeaurora.org>
+Cc: Maulik Shah <mkshah@codeaurora.org>
+Signed-off-by: Stephen Boyd <swboyd@chromium.org>
+Link: https://lore.kernel.org/r/20200121180950.36959-1-swboyd@chromium.org
+Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/qcom/pinctrl-msm.c | 5 -----
+ 1 file changed, 5 deletions(-)
+
+--- a/drivers/pinctrl/qcom/pinctrl-msm.c
++++ b/drivers/pinctrl/qcom/pinctrl-msm.c
+@@ -960,7 +960,6 @@ static int msm_gpio_irq_set_wake(struct
+ {
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
+- unsigned long flags;
+
+ /*
+ * While they may not wake up when the TLMM is powered off,
+@@ -971,12 +970,8 @@ static int msm_gpio_irq_set_wake(struct
+ if (d->parent_data)
+ irq_chip_set_wake_parent(d, on);
+
+- raw_spin_lock_irqsave(&pctrl->lock, flags);
+-
+ irq_set_irq_wake(pctrl->irq, on);
+
+- raw_spin_unlock_irqrestore(&pctrl->lock, flags);
+-
+ return 0;
+ }
+
--- /dev/null
+From 805f635703b2562b5ddd822c62fc9124087e5dd5 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Wed, 18 Dec 2019 20:48:07 +0100
+Subject: pinctrl: sh-pfc: r8a7778: Fix duplicate SDSELF_B and SD1_CLK_B
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 805f635703b2562b5ddd822c62fc9124087e5dd5 upstream.
+
+The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means
+one set of users must be wrong. Replace them by the correct enum IDs.
+
+Fixes: 87f8c988636db0d4 ("sh-pfc: Add r8a7778 pinmux support")
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Link: https://lore.kernel.org/r/20191218194812.12741-2-geert+renesas@glider.be
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
++++ b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
+@@ -2305,7 +2305,7 @@ static const struct pinmux_cfg_reg pinmu
+ FN_ATAG0_A, 0, FN_REMOCON_B, 0,
+ /* IP0_11_8 [4] */
+ FN_SD1_DAT2_A, FN_MMC_D2, 0, FN_BS,
+- FN_ATADIR0_A, 0, FN_SDSELF_B, 0,
++ FN_ATADIR0_A, 0, FN_SDSELF_A, 0,
+ FN_PWM4_B, 0, 0, 0,
+ 0, 0, 0, 0,
+ /* IP0_7_5 [3] */
+@@ -2349,7 +2349,7 @@ static const struct pinmux_cfg_reg pinmu
+ FN_TS_SDAT0_A, 0, 0, 0,
+ 0, 0, 0, 0,
+ /* IP1_10_8 [3] */
+- FN_SD1_CLK_B, FN_MMC_D6, 0, FN_A24,
++ FN_SD1_CD_A, FN_MMC_D6, 0, FN_A24,
+ FN_DREQ1_A, 0, FN_HRX0_B, FN_TS_SPSYNC0_A,
+ /* IP1_7_5 [3] */
+ FN_A23, FN_HTX0_B, FN_TX2_B, FN_DACK2_A,
--- /dev/null
+From a34cd9dfd03fa9ec380405969f1d638bc63b8d63 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Wed, 13 Nov 2019 11:16:53 +0100
+Subject: pinctrl: sh-pfc: r8a77965: Fix DU_DOTCLKIN3 drive/bias control
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit a34cd9dfd03fa9ec380405969f1d638bc63b8d63 upstream.
+
+R-Car Gen3 Hardware Manual Errata for Rev. 2.00 of October 24, 2019
+changed the configuration bits for drive and bias control for the
+DU_DOTCLKIN3 pin on R-Car M3-N, to match the same pin on R-Car H3.
+Update the driver to reflect this.
+
+After this, the handling of drive and bias control for the various
+DU_DOTCLKINx pins is consistent across all of the R-Car H3, M3-W,
+M3-W+, and M3-N SoCs.
+
+Fixes: 86c045c2e4201e94 ("pinctrl: sh-pfc: r8a77965: Replace DU_DOTCLKIN2 by DU_DOTCLKIN3")
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Link: https://lore.kernel.org/r/20191113101653.28428-1-geert+renesas@glider.be
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
++++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+@@ -5998,7 +5998,7 @@ static const struct pinmux_drive_reg pin
+ { PIN_DU_DOTCLKIN1, 0, 2 }, /* DU_DOTCLKIN1 */
+ } },
+ { PINMUX_DRIVE_REG("DRVCTRL12", 0xe6060330) {
+- { PIN_DU_DOTCLKIN3, 28, 2 }, /* DU_DOTCLKIN3 */
++ { PIN_DU_DOTCLKIN3, 24, 2 }, /* DU_DOTCLKIN3 */
+ { PIN_FSCLKST, 20, 2 }, /* FSCLKST */
+ { PIN_TMS, 4, 2 }, /* TMS */
+ } },
+@@ -6254,8 +6254,8 @@ static const struct pinmux_bias_reg pinm
+ [31] = PIN_DU_DOTCLKIN1, /* DU_DOTCLKIN1 */
+ } },
+ { PINMUX_BIAS_REG("PUEN3", 0xe606040c, "PUD3", 0xe606044c) {
+- [ 0] = PIN_DU_DOTCLKIN3, /* DU_DOTCLKIN3 */
+- [ 1] = SH_PFC_PIN_NONE,
++ [ 0] = SH_PFC_PIN_NONE,
++ [ 1] = PIN_DU_DOTCLKIN3, /* DU_DOTCLKIN3 */
+ [ 2] = PIN_FSCLKST, /* FSCLKST */
+ [ 3] = PIN_EXTALR, /* EXTALR*/
+ [ 4] = PIN_TRST_N, /* TRST# */
--- /dev/null
+From 2e31aab08bad0d4ee3d3d890a7b74cb6293e0a41 Mon Sep 17 00:00:00 2001
+From: Ben Whitten <ben.whitten@gmail.com>
+Date: Sat, 18 Jan 2020 20:56:24 +0000
+Subject: regmap: fix writes to non incrementing registers
+
+From: Ben Whitten <ben.whitten@gmail.com>
+
+commit 2e31aab08bad0d4ee3d3d890a7b74cb6293e0a41 upstream.
+
+When checking if a register block is writable we must ensure that the
+block does not start with or contain a non incrementing register.
+
+Fixes: 8b9f9d4dc511 ("regmap: verify if register is writeable before writing operations")
+Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
+Link: https://lore.kernel.org/r/20200118205625.14532-1-ben.whitten@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/regmap/regmap.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/base/regmap/regmap.c
++++ b/drivers/base/regmap/regmap.c
+@@ -1488,11 +1488,18 @@ static int _regmap_raw_write_impl(struct
+
+ WARN_ON(!map->bus);
+
+- /* Check for unwritable registers before we start */
+- for (i = 0; i < val_len / map->format.val_bytes; i++)
+- if (!regmap_writeable(map,
+- reg + regmap_get_offset(map, i)))
+- return -EINVAL;
++ /* Check for unwritable or noinc registers in range
++ * before we start
++ */
++ if (!regmap_writeable_noinc(map, reg)) {
++ for (i = 0; i < val_len / map->format.val_bytes; i++) {
++ unsigned int element =
++ reg + regmap_get_offset(map, i);
++ if (!regmap_writeable(map, element) ||
++ regmap_writeable_noinc(map, element))
++ return -EINVAL;
++ }
++ }
+
+ if (!map->cache_bypass && map->format.parse_val) {
+ unsigned int ival;
--- /dev/null
+From 7226017ad37a888915628e59a84a2d1e57b40707 Mon Sep 17 00:00:00 2001
+From: Qais Yousef <qais.yousef@arm.com>
+Date: Tue, 24 Dec 2019 11:54:04 +0000
+Subject: sched/uclamp: Fix a bug in propagating uclamp value in new cgroups
+
+From: Qais Yousef <qais.yousef@arm.com>
+
+commit 7226017ad37a888915628e59a84a2d1e57b40707 upstream.
+
+When a new cgroup is created, the effective uclamp value wasn't updated
+with a call to cpu_util_update_eff() that looks at the hierarchy and
+update to the most restrictive values.
+
+Fix it by ensuring to call cpu_util_update_eff() when a new cgroup
+becomes online.
+
+Without this change, the newly created cgroup uses the default
+root_task_group uclamp values, which is 1024 for both uclamp_{min, max},
+which will cause the rq to to be clamped to max, hence cause the
+system to run at max frequency.
+
+The problem was observed on Ubuntu server and was reproduced on Debian
+and Buildroot rootfs.
+
+By default, Ubuntu and Debian create a cpu controller cgroup hierarchy
+and add all tasks to it - which creates enough noise to keep the rq
+uclamp value at max most of the time. Imitating this behavior makes the
+problem visible in Buildroot too which otherwise looks fine since it's a
+minimal userspace.
+
+Fixes: 0b60ba2dd342 ("sched/uclamp: Propagate parent clamps")
+Reported-by: Doug Smythies <dsmythies@telus.net>
+Signed-off-by: Qais Yousef <qais.yousef@arm.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Tested-by: Doug Smythies <dsmythies@telus.net>
+Link: https://lore.kernel.org/lkml/000701d5b965$361b6c60$a2524520$@net/
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/sched/core.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -7100,6 +7100,12 @@ static int cpu_cgroup_css_online(struct
+
+ if (parent)
+ sched_online_group(tg, parent);
++
++#ifdef CONFIG_UCLAMP_TASK_GROUP
++ /* Propagate the effective uclamp value for the new group */
++ cpu_util_update_eff(css);
++#endif
++
+ return 0;
+ }
+
--- /dev/null
+From 98aa00345de54b8340dc2ddcd87f446d33387b5e Mon Sep 17 00:00:00 2001
+From: Stephen Smalley <sds@tycho.nsa.gov>
+Date: Fri, 17 Jan 2020 15:24:07 -0500
+Subject: selinux: fix regression introduced by move_mount(2) syscall
+
+From: Stephen Smalley <sds@tycho.nsa.gov>
+
+commit 98aa00345de54b8340dc2ddcd87f446d33387b5e upstream.
+
+commit 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")
+introduced a new move_mount(2) system call and a corresponding new LSM
+security_move_mount hook but did not implement this hook for any existing
+LSM. This creates a regression for SELinux with respect to consistent
+checking of mounts; the existing selinux_mount hook checks mounton
+permission to the mount point path. Provide a SELinux hook
+implementation for move_mount that applies this same check for
+consistency. In the future we may wish to add a new move_mount
+filesystem permission and check as well, but this addresses
+the immediate regression.
+
+Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")
+Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
+Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/selinux/hooks.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/security/selinux/hooks.c
++++ b/security/selinux/hooks.c
+@@ -2762,6 +2762,14 @@ static int selinux_mount(const char *dev
+ return path_has_perm(cred, path, FILE__MOUNTON);
+ }
+
++static int selinux_move_mount(const struct path *from_path,
++ const struct path *to_path)
++{
++ const struct cred *cred = current_cred();
++
++ return path_has_perm(cred, to_path, FILE__MOUNTON);
++}
++
+ static int selinux_umount(struct vfsmount *mnt, int flags)
+ {
+ const struct cred *cred = current_cred();
+@@ -6904,6 +6912,8 @@ static struct security_hook_list selinux
+ LSM_HOOK_INIT(sb_clone_mnt_opts, selinux_sb_clone_mnt_opts),
+ LSM_HOOK_INIT(sb_add_mnt_opt, selinux_add_mnt_opt),
+
++ LSM_HOOK_INIT(move_mount, selinux_move_mount),
++
+ LSM_HOOK_INIT(dentry_init_security, selinux_dentry_init_security),
+ LSM_HOOK_INIT(dentry_create_files_as, selinux_dentry_create_files_as),
+
--- /dev/null
+From 1a37079c236d55fb31ebbf4b59945dab8ec8764c Mon Sep 17 00:00:00 2001
+From: Stephen Smalley <sds@tycho.nsa.gov>
+Date: Fri, 22 Nov 2019 12:22:44 -0500
+Subject: selinux: revert "stop passing MAY_NOT_BLOCK to the AVC upon follow_link"
+
+From: Stephen Smalley <sds@tycho.nsa.gov>
+
+commit 1a37079c236d55fb31ebbf4b59945dab8ec8764c upstream.
+
+This reverts commit e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK
+to the AVC upon follow_link"). The correct fix is to instead fall
+back to ref-walk if audit is required irrespective of the specific
+audit data type. This is done in the next commit.
+
+Fixes: e46e01eebbbc ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link")
+Reported-by: Will Deacon <will@kernel.org>
+Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/selinux/avc.c | 24 ++++++++++++++++++++++--
+ security/selinux/hooks.c | 5 +++--
+ security/selinux/include/avc.h | 5 +++++
+ 3 files changed, 30 insertions(+), 4 deletions(-)
+
+--- a/security/selinux/avc.c
++++ b/security/selinux/avc.c
+@@ -862,8 +862,9 @@ static int avc_update_node(struct selinu
+ * permissive mode that only appear when in enforcing mode.
+ *
+ * See the corresponding handling in slow_avc_audit(), and the
+- * logic in selinux_inode_permission for the MAY_NOT_BLOCK flag,
+- * which is transliterated into AVC_NONBLOCKING.
++ * logic in selinux_inode_follow_link and selinux_inode_permission
++ * for the VFS MAY_NOT_BLOCK flag, which is transliterated into
++ * AVC_NONBLOCKING for avc_has_perm_noaudit().
+ */
+ if (flags & AVC_NONBLOCKING)
+ return 0;
+@@ -1203,6 +1204,25 @@ int avc_has_perm(struct selinux_state *s
+ if (rc2)
+ return rc2;
+ return rc;
++}
++
++int avc_has_perm_flags(struct selinux_state *state,
++ u32 ssid, u32 tsid, u16 tclass, u32 requested,
++ struct common_audit_data *auditdata,
++ int flags)
++{
++ struct av_decision avd;
++ int rc, rc2;
++
++ rc = avc_has_perm_noaudit(state, ssid, tsid, tclass, requested,
++ (flags & MAY_NOT_BLOCK) ? AVC_NONBLOCKING : 0,
++ &avd);
++
++ rc2 = avc_audit(state, ssid, tsid, tclass, requested, &avd, rc,
++ auditdata, flags);
++ if (rc2)
++ return rc2;
++ return rc;
+ }
+
+ u32 avc_policy_seqno(struct selinux_state *state)
+--- a/security/selinux/hooks.c
++++ b/security/selinux/hooks.c
+@@ -3004,8 +3004,9 @@ static int selinux_inode_follow_link(str
+ if (IS_ERR(isec))
+ return PTR_ERR(isec);
+
+- return avc_has_perm(&selinux_state,
+- sid, isec->sid, isec->sclass, FILE__READ, &ad);
++ return avc_has_perm_flags(&selinux_state,
++ sid, isec->sid, isec->sclass, FILE__READ, &ad,
++ rcu ? MAY_NOT_BLOCK : 0);
+ }
+
+ static noinline int audit_inode_permission(struct inode *inode,
+--- a/security/selinux/include/avc.h
++++ b/security/selinux/include/avc.h
+@@ -153,6 +153,11 @@ int avc_has_perm(struct selinux_state *s
+ u32 ssid, u32 tsid,
+ u16 tclass, u32 requested,
+ struct common_audit_data *auditdata);
++int avc_has_perm_flags(struct selinux_state *state,
++ u32 ssid, u32 tsid,
++ u16 tclass, u32 requested,
++ struct common_audit_data *auditdata,
++ int flags);
+
+ int avc_has_extended_perms(struct selinux_state *state,
+ u32 ssid, u32 tsid, u16 tclass, u32 requested,
powerpc-papr_scm-fix-leaking-bus_desc.provider_name-in-some-paths.patch
powerpc-pseries-vio-fix-iommu_table-use-after-free-refcount-warning.patch
powerpc-pseries-allow-not-having-ibm-hypertas-functions-hcall-multi-tce-for-ddw.patch
+iommu-arm-smmu-v3-populate-vmid-field-for-cmdq_op_tlbi_nh_va.patch
+arm-at91-pm-use-sam9x60-pmc-s-compatible.patch
+arm-at91-pm-use-of_device_id-array-to-find-the-proper-shdwc-node.patch
+kvm-arm-arm64-vgic-its-fix-restoration-of-unmapped-collections.patch
+arm-8949-1-mm-mark-free_memmap-as-__init.patch
+sched-uclamp-fix-a-bug-in-propagating-uclamp-value-in-new-cgroups.patch
+arm64-kernel-correct-annotation-of-end-of-el0_sync.patch
+arm64-cpufeature-fix-the-type-of-no-fp-simd-capability.patch
+arm64-cpufeature-set-the-fp-simd-compat-hwcap-bits-properly.patch
+arm64-ptrace-nofpsimd-fail-fp-simd-regset-operations.patch
+crypto-arm-chacha-fix-build-failured-when-kernel-mode-neon-is-disabled.patch
+kvm-arm-arm64-fix-young-bit-from-mmu-notifier.patch
+kvm-arm-fix-dfsr-setting-for-non-lpae-aarch32-guests.patch
+kvm-arm-make-inject_abt32-inject-an-external-abort-instead.patch
+kvm-arm64-pmu-don-t-increment-sw_incr-if-pmcr.e-is-unset.patch
+kvm-arm64-pmu-fix-chained-sw_incr-counters.patch
+kvm-arm64-treat-emulated-tval-timervalue-as-a-signed-32-bit-integer.patch
+arm64-nofpsmid-handle-tif_foreign_fpstate-flag-cleanly.patch
+arm64-kvm-fix-idmap-overlap-with-hyp-va.patch
+mtd-onenand_base-adjust-indentation-in-onenand_read_ops_nolock.patch
+mtd-sharpslpart-fix-unsigned-comparison-to-zero.patch
+crypto-testmgr-don-t-try-to-decrypt-uninitialized-buffers.patch
+crypto-artpec6-return-correct-error-code-for-failed-setkey.patch
+crypto-atmel-sha-fix-error-handling-when-setting-hmac-key.patch
+crypto-caam-qi2-fix-typo-in-algorithm-s-driver-name.patch
+drivers-watchdog-stm32_iwdg-set-wdog_hw_running-at-probe.patch
+media-i2c-adv748x-fix-unsafe-macros.patch
+i2c-cros-ec-tunnel-fix-slave-device-enumeration.patch
+i2c-cros-ec-tunnel-fix-acpi-identifier.patch
+dt-bindings-iio-adc-ad7606-fix-wrong-maxitems-value.patch
+asoc-soc-generic-dmaengine-pcm-fix-error-handling.patch
+bcache-avoid-unnecessary-btree-nodes-flushing-in-btree_flush_write.patch
+x86-alternatives-add-missing-insn.h-include.patch
+x86-alternatives-sync-bp_patching-update-for-avoiding-null-pointer-exception.patch
+selinux-revert-stop-passing-may_not_block-to-the-avc-upon-follow_link.patch
+selinux-fix-regression-introduced-by-move_mount-2-syscall.patch
+pinctrl-baytrail-allocate-irq-chip-dynamic.patch
+pinctrl-sh-pfc-r8a77965-fix-du_dotclkin3-drive-bias-control.patch
+pinctrl-sh-pfc-r8a7778-fix-duplicate-sdself_b-and-sd1_clk_b.patch
+pinctrl-qcom-don-t-lock-around-irq_set_irq_wake.patch
+regmap-fix-writes-to-non-incrementing-registers.patch
+mfd-max77650-select-regmap_irq-in-kconfig.patch
+clk-meson-g12a-fix-missing-uart2-in-regmap-table.patch
+dmaengine-axi-dmac-add-a-check-for-devm_regmap_init_mmio.patch
--- /dev/null
+From 3a1255396b5aba40299d5dd5bde67b160a44117f Mon Sep 17 00:00:00 2001
+From: Dave Hansen <dave.hansen@linux.intel.com>
+Date: Thu, 23 Jan 2020 10:41:13 -0800
+Subject: x86/alternatives: add missing insn.h include
+
+From: Dave Hansen <dave.hansen@linux.intel.com>
+
+commit 3a1255396b5aba40299d5dd5bde67b160a44117f upstream.
+
+From: Dave Hansen <dave.hansen@linux.intel.com>
+
+While testing my MPX removal series, Borislav noted compilation
+failure with an allnoconfig build.
+
+Turned out to be a missing include of insn.h in alternative.c.
+With MPX, it got it implicitly from:
+
+ asm/mmu_context.h -> asm/mpx.h -> asm/insn.h
+
+Fixes: c3d6324f841b ("x86/alternatives: Teach text_poke_bp() to emulate instructions")
+Reported-by: Borislav Petkov <bp@alien8.de>
+Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: x86@kernel.org
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/alternative.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/alternative.c
++++ b/arch/x86/kernel/alternative.c
+@@ -23,6 +23,7 @@
+ #include <asm/nmi.h>
+ #include <asm/cacheflush.h>
+ #include <asm/tlbflush.h>
++#include <asm/insn.h>
+ #include <asm/io.h>
+ #include <asm/fixmap.h>
+
--- /dev/null
+From 285a54efe3861976af9d15e85ff8c91a78d1407b Mon Sep 17 00:00:00 2001
+From: Masami Hiramatsu <mhiramat@kernel.org>
+Date: Wed, 27 Nov 2019 14:56:52 +0900
+Subject: x86/alternatives: Sync bp_patching update for avoiding NULL pointer exception
+
+From: Masami Hiramatsu <mhiramat@kernel.org>
+
+commit 285a54efe3861976af9d15e85ff8c91a78d1407b upstream.
+
+ftracetest multiple_kprobes.tc testcase hits the following NULL pointer
+exception:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000000
+ PGD 800000007bf60067 P4D 800000007bf60067 PUD 7bf5f067 PMD 0
+ Oops: 0000 [#1] PREEMPT SMP PTI
+ RIP: 0010:poke_int3_handler+0x39/0x100
+ Call Trace:
+ <IRQ>
+ do_int3+0xd/0xf0
+ int3+0x42/0x50
+ RIP: 0010:sched_clock+0x6/0x10
+
+poke_int3_handler+0x39 was alternatives:958:
+
+ static inline void *text_poke_addr(struct text_poke_loc *tp)
+ {
+ return _stext + tp->rel_addr; <------ Here is line #958
+ }
+
+This seems to be caused by tp (bp_patching.vec) being NULL but
+bp_patching.nr_entries != 0. There is a small chance for this
+to happen, because we have no synchronization between the zeroing
+of bp_patching.nr_entries and before clearing bp_patching.vec.
+
+Steve suggested we could fix this by adding sync_core(), because int3
+is done with interrupts disabled, and the on_each_cpu() requires
+all CPUs to have had their interrupts enabled.
+
+ [ mingo: Edited the comments and the changelog. ]
+
+Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Tested-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: bristot@redhat.com
+Fixes: c0213b0ac03c ("x86/alternative: Batch of patch operations")
+Link: https://lkml.kernel.org/r/157483421229.25881.15314414408559963162.stgit@devnote2
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/alternative.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/alternative.c
++++ b/arch/x86/kernel/alternative.c
+@@ -1110,8 +1110,14 @@ void text_poke_bp_batch(struct text_poke
+ * sync_core() implies an smp_mb() and orders this store against
+ * the writing of the new instruction.
+ */
+- bp_patching.vec = NULL;
+ bp_patching.nr_entries = 0;
++ /*
++ * This sync_core () call ensures that all INT3 handlers in progress
++ * have finished. This allows poke_int3_handler() after this to
++ * avoid touching bp_paching.vec by checking nr_entries == 0.
++ */
++ text_poke_sync();
++ bp_patching.vec = NULL;
+ }
+
+ void text_poke_loc_init(struct text_poke_loc *tp, void *addr,
projects / thirdparty / kernel / stable-queue.git / commitdiff
