--- /dev/null
+From 36904703aeeeb6cd31993f1353c8325006229f9a Mon Sep 17 00:00:00 2001
+From: Kai Heng Feng <kai.heng.feng@canonical.com>
+Date: Mon, 5 Feb 2018 13:19:24 +0800
+Subject: ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530
+
+From: Kai Heng Feng <kai.heng.feng@canonical.com>
+
+commit 36904703aeeeb6cd31993f1353c8325006229f9a upstream.
+
+The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
+of box.
+
+The touchpad relies on its _INI method to update its _HID value from
+XXXX0000 to SYNA2393.
+
+Also, the _STA relies on value of I2CN to report correct status.
+
+Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
+correctly set up, and _INI can get run. The ACPI table in this machine
+is designed to get parsed this way.
+
+Also, change the quirk table to a more generic name.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/bus.c | 38 +++++++++++++++++++++++++++++++-------
+ 1 file changed, 31 insertions(+), 7 deletions(-)
+
+--- a/drivers/acpi/bus.c
++++ b/drivers/acpi/bus.c
+@@ -66,10 +66,37 @@ static int set_copy_dsdt(const struct dm
+ return 0;
+ }
+ #endif
++static int set_gbl_term_list(const struct dmi_system_id *id)
++{
++ acpi_gbl_parse_table_as_term_list = 1;
++ return 0;
++}
+
+-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
++static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = {
++ /*
++ * Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C
++ * mode.
++ * https://bugzilla.kernel.org/show_bug.cgi?id=198515
++ */
++ {
++ .callback = set_gbl_term_list,
++ .ident = "Dell Precision M5530",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"),
++ },
++ },
++ {
++ .callback = set_gbl_term_list,
++ .ident = "Dell XPS 15 9570",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
++ },
++ },
+ /*
+ * Invoke DSDT corruption work-around on all Toshiba Satellite.
++ * DSDT will be copied to memory.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=14679
+ */
+ {
+@@ -83,7 +110,7 @@ static const struct dmi_system_id dsdt_d
+ {}
+ };
+ #else
+-static const struct dmi_system_id dsdt_dmi_table[] __initconst = {
++static const struct dmi_system_id acpi_quirks_dmi_table[] __initconst = {
+ {}
+ };
+ #endif
+@@ -1001,11 +1028,8 @@ void __init acpi_early_init(void)
+
+ acpi_permanent_mmap = true;
+
+- /*
+- * If the machine falls into the DMI check table,
+- * DSDT will be copied to memory
+- */
+- dmi_check_system(dsdt_dmi_table);
++ /* Check machine-specific quirks */
++ dmi_check_system(acpi_quirks_dmi_table);
+
+ status = acpi_reallocate_root_table();
+ if (ACPI_FAILURE(status)) {
--- /dev/null
+From 84c7efd607e7fb6933920322086db64654f669b2 Mon Sep 17 00:00:00 2001
+From: Adam Ford <aford173@gmail.com>
+Date: Sat, 27 Jan 2018 15:27:05 -0600
+Subject: ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux
+
+From: Adam Ford <aford173@gmail.com>
+
+commit 84c7efd607e7fb6933920322086db64654f669b2 upstream.
+
+The pinmuxing was missing for I2C1 which was causing intermittent issues
+with the PMIC which is connected to I2C1. The bootloader did not quite
+configure the I2C1 either, so when running at 2.6MHz, it was generating
+errors at times.
+
+This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz
+
+Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730
+SOM-LV")
+
+Signed-off-by: Adam Ford <aford173@gmail.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/logicpd-som-lv.dtsi | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
++++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
+@@ -98,6 +98,8 @@
+ };
+
+ &i2c1 {
++ pinctrl-names = "default";
++ pinctrl-0 = <&i2c1_pins>;
+ clock-frequency = <2600000>;
+
+ twl: twl@48 {
+@@ -216,7 +218,12 @@
+ >;
+ };
+
+-
++ i2c1_pins: pinmux_i2c1_pins {
++ pinctrl-single,pins = <
++ OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
++ OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
++ >;
++ };
+ };
+
+ &omap3_pmx_wkup {
--- /dev/null
+From 74402055a2d3ec998a1ded599e86185a27d9bbf4 Mon Sep 17 00:00:00 2001
+From: Adam Ford <aford173@gmail.com>
+Date: Thu, 25 Jan 2018 14:10:37 -0600
+Subject: ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux
+
+From: Adam Ford <aford173@gmail.com>
+
+commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.
+
+The pinmuxing was missing for I2C1 which was causing intermittent issues
+with the PMIC which is connected to I2C1. The bootloader did not quite
+configure the I2C1 either, so when running at 2.6MHz, it was generating
+errors at time.
+
+This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz
+
+Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo
+DM3730 devkit")
+
+Signed-off-by: Adam Ford <aford173@gmail.com>
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
++++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+@@ -104,6 +104,8 @@
+ };
+
+ &i2c1 {
++ pinctrl-names = "default";
++ pinctrl-0 = <&i2c1_pins>;
+ clock-frequency = <2600000>;
+
+ twl: twl@48 {
+@@ -211,6 +213,12 @@
+ OMAP3_CORE1_IOPAD(0x21b8, PIN_INPUT | MUX_MODE0) /* hsusb0_data7.hsusb0_data7 */
+ >;
+ };
++ i2c1_pins: pinmux_i2c1_pins {
++ pinctrl-single,pins = <
++ OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
++ OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
++ >;
++ };
+ };
+
+ &uart2 {
--- /dev/null
+From 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.com>
+Date: Sat, 3 Feb 2018 09:19:30 +1100
+Subject: md: only allow remove_and_add_spares when no sync_thread running.
+
+From: NeilBrown <neilb@suse.com>
+
+commit 39772f0a7be3b3dc26c74ea13fe7847fd1522c8b upstream.
+
+The locking protocols in md assume that a device will
+never be removed from an array during resync/recovery/reshape.
+When that isn't happening, rcu or reconfig_mutex is needed
+to protect an rdev pointer while taking a refcount. When
+it is happening, that protection isn't needed.
+
+Unfortunately there are cases were remove_and_add_spares() is
+called when recovery might be happening: is state_store(),
+slot_store() and hot_remove_disk().
+In each case, this is just an optimization, to try to expedite
+removal from the personality so the device can be removed from
+the array. If resync etc is happening, we just have to wait
+for md_check_recover to find a suitable time to call
+remove_and_add_spares().
+
+This optimization and not essential so it doesn't
+matter if it fails.
+So change remove_and_add_spares() to abort early if
+resync/recovery/reshape is happening, unless it is called
+from md_check_recovery() as part of a newly started recovery.
+The parameter "this" is only NULL when called from
+md_check_recovery() so when it is NULL, there is no need to abort.
+
+As this can result in a NULL dereference, the fix is suitable
+for -stable.
+
+cc: yuyufen <yuyufen@huawei.com>
+Cc: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
+Fixes: 8430e7e0af9a ("md: disconnect device from personality before trying to remove it.")
+Cc: stable@ver.kernel.org (v4.8+)
+Signed-off-by: NeilBrown <neilb@suse.com>
+Signed-off-by: Shaohua Li <sh.li@alibaba-inc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/md.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -8554,6 +8554,10 @@ static int remove_and_add_spares(struct
+ int removed = 0;
+ bool remove_some = false;
+
++ if (this && test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
++ /* Mustn't remove devices when resync thread is running */
++ return 0;
++
+ rdev_for_each(rdev, mddev) {
+ if ((this == NULL || rdev == this) &&
+ rdev->raid_disk >= 0 &&
--- /dev/null
+From eeb715c3e995fbdda0cc05e61216c6c5609bce66 Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Wed, 7 Feb 2018 11:20:02 +1000
+Subject: powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PID
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit eeb715c3e995fbdda0cc05e61216c6c5609bce66 upstream.
+
+This change restores and formalises the behaviour that access to NULL
+or other user addresses by the kernel during boot should fault rather
+than succeed and modify memory. This was inadvertently broken when
+fixing another bug, because it was previously not well defined and
+only worked by chance.
+
+powerpc/64s/radix uses high address bits to select an address space
+"quadrant", which determines which PID and LPID are used to translate
+the rest of the address (effective PID, effective LPID). The kernel
+mapping at 0xC... selects quadrant 3, which uses PID=0 and LPID=0. So
+the kernel page tables are installed in the PID 0 process table entry.
+
+An address at 0x0... selects quadrant 0, which uses PID=PIDR for
+translating the rest of the address (that is, it uses the value of the
+PIDR register as the effective PID). If PIDR=0, then the translation
+is performed with the PID 0 process table entry page tables. This is
+the kernel mapping, so we effectively get another copy of the kernel
+address space at 0. A NULL pointer access will access physical memory
+address 0.
+
+To prevent duplicating the kernel address space in quadrant 0, this
+patch allocates a guard PID containing no translations, and
+initializes PIDR with this during boot, before the MMU is switched on.
+Any kernel access to quadrant 0 will use this guard PID for
+translation and find no valid mappings, and therefore fault.
+
+After boot, this PID will be switchd away to user context PIDs, but
+those contain user mappings (and usually NULL pointer protection)
+rather than kernel mapping, which is much safer (and by design). It
+may be in future this is tightened further, which the guard PID could
+be used for.
+
+Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before
+setting partition table"), introduced this problem because it zeroes
+PIDR at boot. However previously the value was inherited from firmware
+or kexec, which is not robust and can be zero (e.g., mambo).
+
+Fixes: 371b80447ff3 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table")
+Cc: stable@vger.kernel.org # v4.15+
+Reported-by: Florian Weimer <fweimer@redhat.com>
+Tested-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+[mauricfo: backport to v4.15.7 (context line updates only) and re-test]
+Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
+Acked-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/mm/pgtable-radix.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/arch/powerpc/mm/pgtable-radix.c
++++ b/arch/powerpc/mm/pgtable-radix.c
+@@ -21,6 +21,7 @@
+
+ #include <asm/pgtable.h>
+ #include <asm/pgalloc.h>
++#include <asm/mmu_context.h>
+ #include <asm/dma.h>
+ #include <asm/machdep.h>
+ #include <asm/mmu.h>
+@@ -334,6 +335,22 @@ static void __init radix_init_pgtable(vo
+ "r" (TLBIEL_INVAL_SET_LPID), "r" (0));
+ asm volatile("eieio; tlbsync; ptesync" : : : "memory");
+ trace_tlbie(0, 0, TLBIEL_INVAL_SET_LPID, 0, 2, 1, 1);
++
++ /*
++ * The init_mm context is given the first available (non-zero) PID,
++ * which is the "guard PID" and contains no page table. PIDR should
++ * never be set to zero because that duplicates the kernel address
++ * space at the 0x0... offset (quadrant 0)!
++ *
++ * An arbitrary PID that may later be allocated by the PID allocator
++ * for userspace processes must not be used either, because that
++ * would cause stale user mappings for that PID on CPUs outside of
++ * the TLB invalidation scheme (because it won't be in mm_cpumask).
++ *
++ * So permanently carve out one PID for the purpose of a guard PID.
++ */
++ init_mm.context.id = mmu_base_pid;
++ mmu_base_pid++;
+ }
+
+ static void __init radix_init_partition_table(void)
+@@ -580,6 +597,8 @@ void __init radix__early_init_mmu(void)
+
+ radix_init_iamr();
+ radix_init_pgtable();
++ /* Switch to the guard PID before turning on MMU */
++ radix__switch_mmu_context(NULL, &init_mm);
+ }
+
+ void radix__early_init_mmu_secondary(void)
+@@ -601,6 +620,7 @@ void radix__early_init_mmu_secondary(voi
+ radix_init_amor();
+ }
+ radix_init_iamr();
++ radix__switch_mmu_context(NULL, &init_mm);
+ }
+
+ void radix__mmu_cleanup_all(void)
kvm-vmx-optimize-vmx_vcpu_run-and-svm_vcpu_run-by-marking-the-rdmsr-path-as-unlikely.patch
kvm-x86-fix-vcpu-initialization-with-userspace-lapic.patch
kvm-x86-remove-warn_on-for-when-vm_munmap-fails.patch
+acpi-bus-parse-tables-as-term_list-for-dell-xps-9570-and-precision-m5530.patch
+arm-dts-logicpd-som-lv-fix-i2c1-pinmux.patch
+arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch
+powerpc-64s-radix-boot-time-null-pointer-protection-using-a-guard-pid.patch
+md-only-allow-remove_and_add_spares-when-no-sync_thread-running.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
