From: Greg Kroah-Hartman Date: Thu, 3 Oct 2019 08:48:03 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.4.195~40 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5a5f4738e7cab326cdab8f1a0af4d1e3736591fd;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch arm-zynq-use-memcpy_toio-instead-of-memcpy-on-smp-bring-up.patch asoc-intel-fix-use-of-potentially-uninitialized-variable.patch asoc-intel-nhlt-fix-debug-print-format.patch media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch regulator-defer-init-completion-for-a-while-after-late_initcall.patch --- diff --git a/queue-4.9/alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch b/queue-4.9/alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch new file mode 100644 index 00000000000..1c783e622de --- /dev/null +++ b/queue-4.9/alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch @@ -0,0 +1,49 @@ +From f18ddc13af981ce3c7b7f26925f099e7c6929aba Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +Date: Tue, 3 Sep 2019 14:18:02 -0300 +Subject: alarmtimer: Use EOPNOTSUPP instead of ENOTSUPP + +From: Thadeu Lima de Souza Cascardo + +commit f18ddc13af981ce3c7b7f26925f099e7c6929aba upstream. + +ENOTSUPP is not supposed to be returned to userspace. This was found on an +OpenPower machine, where the RTC does not support set_alarm. + +On that system, a clock_nanosleep(CLOCK_REALTIME_ALARM, ...) results in +"524 Unknown error 524" + +Replace it with EOPNOTSUPP which results in the expected "95 Operation not +supported" error. + +Fixes: 1c6b39ad3f01 (alarmtimers: Return -ENOTSUPP if no RTC device is present) +Signed-off-by: Thadeu Lima de Souza Cascardo +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190903171802.28314-1-cascardo@canonical.com +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/time/alarmtimer.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/time/alarmtimer.c ++++ b/kernel/time/alarmtimer.c +@@ -544,7 +544,7 @@ static int alarm_timer_create(struct k_i + enum alarmtimer_type type; + + if (!alarmtimer_get_rtcdev()) +- return -ENOTSUPP; ++ return -EOPNOTSUPP; + + if (!capable(CAP_WAKE_ALARM)) + return -EPERM; +@@ -772,7 +772,7 @@ static int alarm_timer_nsleep(const cloc + struct restart_block *restart; + + if (!alarmtimer_get_rtcdev()) +- return -ENOTSUPP; ++ return -EOPNOTSUPP; + + if (flags & ~TIMER_ABSTIME) + return -EINVAL; diff --git a/queue-4.9/arm-zynq-use-memcpy_toio-instead-of-memcpy-on-smp-bring-up.patch b/queue-4.9/arm-zynq-use-memcpy_toio-instead-of-memcpy-on-smp-bring-up.patch new file mode 100644 index 00000000000..6b1be0506ce --- /dev/null +++ b/queue-4.9/arm-zynq-use-memcpy_toio-instead-of-memcpy-on-smp-bring-up.patch @@ -0,0 +1,48 @@ +From b7005d4ef4f3aa2dc24019ffba03a322557ac43d Mon Sep 17 00:00:00 2001 +From: Luis Araneda +Date: Thu, 8 Aug 2019 08:52:43 -0400 +Subject: ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up + +From: Luis Araneda + +commit b7005d4ef4f3aa2dc24019ffba03a322557ac43d upstream. + +This fixes a kernel panic on memcpy when +FORTIFY_SOURCE is enabled. + +The initial smp implementation on commit aa7eb2bb4e4a +("arm: zynq: Add smp support") +used memcpy, which worked fine until commit ee333554fed5 +("ARM: 8749/1: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE") +enabled overflow checks at runtime, producing a read +overflow panic. + +The computed size of memcpy args are: +- p_size (dst): 4294967295 = (size_t) -1 +- q_size (src): 1 +- size (len): 8 + +Additionally, the memory is marked as __iomem, so one of +the memcpy_* functions should be used for read/write. + +Fixes: aa7eb2bb4e4a ("arm: zynq: Add smp support") +Signed-off-by: Luis Araneda +Cc: stable@vger.kernel.org +Signed-off-by: Michal Simek +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-zynq/platsmp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/mach-zynq/platsmp.c ++++ b/arch/arm/mach-zynq/platsmp.c +@@ -65,7 +65,7 @@ int zynq_cpun_start(u32 address, int cpu + * 0x4: Jump by mov instruction + * 0x8: Jumping address + */ +- memcpy((__force void *)zero, &zynq_secondary_trampoline, ++ memcpy_toio(zero, &zynq_secondary_trampoline, + trampoline_size); + writel(address, zero + trampoline_size); + diff --git a/queue-4.9/asoc-intel-fix-use-of-potentially-uninitialized-variable.patch b/queue-4.9/asoc-intel-fix-use-of-potentially-uninitialized-variable.patch new file mode 100644 index 00000000000..2e5ef932be5 --- /dev/null +++ b/queue-4.9/asoc-intel-fix-use-of-potentially-uninitialized-variable.patch @@ -0,0 +1,41 @@ +From 810f3b860850148788fc1ed8a6f5f807199fed65 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?= + +Date: Tue, 27 Aug 2019 16:17:08 +0200 +Subject: ASoC: Intel: Fix use of potentially uninitialized variable +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Amadeusz Sławiński + +commit 810f3b860850148788fc1ed8a6f5f807199fed65 upstream. + +If ipc->ops.reply_msg_match is NULL, we may end up using uninitialized +mask value. + +reported by smatch: +sound/soc/intel/common/sst-ipc.c:266 sst_ipc_reply_find_msg() error: uninitialized symbol 'mask'. + +Signed-off-by: Amadeusz Sławiński +Link: https://lore.kernel.org/r/20190827141712.21015-3-amadeuszx.slawinski@linux.intel.com +Reviewed-by: Pierre-Louis Bossart +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/intel/common/sst-ipc.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/soc/intel/common/sst-ipc.c ++++ b/sound/soc/intel/common/sst-ipc.c +@@ -211,6 +211,8 @@ struct ipc_message *sst_ipc_reply_find_m + + if (ipc->ops.reply_msg_match != NULL) + header = ipc->ops.reply_msg_match(header, &mask); ++ else ++ mask = (u64)-1; + + if (list_empty(&ipc->rx_list)) { + dev_err(ipc->dev, "error: rx list empty but received 0x%llx\n", diff --git a/queue-4.9/asoc-intel-nhlt-fix-debug-print-format.patch b/queue-4.9/asoc-intel-nhlt-fix-debug-print-format.patch new file mode 100644 index 00000000000..9ae52ee01ff --- /dev/null +++ b/queue-4.9/asoc-intel-nhlt-fix-debug-print-format.patch @@ -0,0 +1,38 @@ +From 855a06da37a773fd073d51023ac9d07988c87da8 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?= + +Date: Tue, 27 Aug 2019 16:17:12 +0200 +Subject: ASoC: Intel: NHLT: Fix debug print format +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Amadeusz Sławiński + +commit 855a06da37a773fd073d51023ac9d07988c87da8 upstream. + +oem_table_id is 8 chars long, so we need to limit it, otherwise it +may print some unprintable characters into dmesg. + +Signed-off-by: Amadeusz Sławiński +Link: https://lore.kernel.org/r/20190827141712.21015-7-amadeuszx.slawinski@linux.intel.com +Reviewed-by: Pierre-Louis Bossart +Signed-off-by: Mark Brown +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + sound/soc/intel/skylake/skl-nhlt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/intel/skylake/skl-nhlt.c ++++ b/sound/soc/intel/skylake/skl-nhlt.c +@@ -211,7 +211,7 @@ int skl_nhlt_update_topology_bin(struct + struct hdac_bus *bus = ebus_to_hbus(&skl->ebus); + struct device *dev = bus->dev; + +- dev_dbg(dev, "oem_id %.6s, oem_table_id %8s oem_revision %d\n", ++ dev_dbg(dev, "oem_id %.6s, oem_table_id %.8s oem_revision %d\n", + nhlt->header.oem_id, nhlt->header.oem_table_id, + nhlt->header.oem_revision); + diff --git a/queue-4.9/media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch b/queue-4.9/media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch new file mode 100644 index 00000000000..8966c48afe3 --- /dev/null +++ b/queue-4.9/media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch @@ -0,0 +1,41 @@ +From 7e0bb5828311f811309bed5749528ca04992af2f Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Sun, 18 Aug 2019 12:03:23 -0300 +Subject: media: sn9c20x: Add MSI MS-1039 laptop to flip_dmi_table + +From: Hans de Goede + +commit 7e0bb5828311f811309bed5749528ca04992af2f upstream. + +Like a bunch of other MSI laptops the MS-1039 uses a 0c45:627b +SN9C201 + OV7660 webcam which is mounted upside down. + +Add it to the sn9c20x flip_dmi_table to deal with this. + +Cc: stable@vger.kernel.org +Reported-by: Rui Salvaterra +Signed-off-by: Hans de Goede +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/usb/gspca/sn9c20x.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/media/usb/gspca/sn9c20x.c ++++ b/drivers/media/usb/gspca/sn9c20x.c +@@ -138,6 +138,13 @@ static const struct dmi_system_id flip_d + } + }, + { ++ .ident = "MSI MS-1039", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "MICRO-STAR INT'L CO.,LTD."), ++ DMI_MATCH(DMI_PRODUCT_NAME, "MS-1039"), ++ } ++ }, ++ { + .ident = "MSI MS-1632", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "MSI"), diff --git a/queue-4.9/regulator-defer-init-completion-for-a-while-after-late_initcall.patch b/queue-4.9/regulator-defer-init-completion-for-a-while-after-late_initcall.patch new file mode 100644 index 00000000000..581fa57307e --- /dev/null +++ b/queue-4.9/regulator-defer-init-completion-for-a-while-after-late_initcall.patch @@ -0,0 +1,104 @@ +From 55576cf1853798e86f620766e23b604c9224c19c Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Wed, 4 Sep 2019 13:42:50 +0100 +Subject: regulator: Defer init completion for a while after late_initcall + +From: Mark Brown + +commit 55576cf1853798e86f620766e23b604c9224c19c upstream. + +The kernel has no way of knowing when we have finished instantiating +drivers, between deferred probe and systems that build key drivers as +modules we might be doing this long after userspace has booted. This has +always been a bit of an issue with regulator_init_complete since it can +power off hardware that's not had it's driver loaded which can result in +user visible effects, the main case is powering off displays. Practically +speaking it's not been an issue in real systems since most systems that +use the regulator API are embedded and build in key drivers anyway but +with Arm laptops coming on the market it's becoming more of an issue so +let's do something about it. + +In the absence of any better idea just defer the powering off for 30s +after late_initcall(), this is obviously a hack but it should mask the +issue for now and it's no more arbitrary than late_initcall() itself. +Ideally we'd have some heuristics to detect if we're on an affected +system and tune or skip the delay appropriately, and there may be some +need for a command line option to be added. + +Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org +Signed-off-by: Mark Brown +Tested-by: Lee Jones +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/regulator/core.c | 42 +++++++++++++++++++++++++++++++----------- + 1 file changed, 31 insertions(+), 11 deletions(-) + +--- a/drivers/regulator/core.c ++++ b/drivers/regulator/core.c +@@ -4452,7 +4452,7 @@ static int __init regulator_init(void) + /* init early to allow our consumers to complete system booting */ + core_initcall(regulator_init); + +-static int __init regulator_late_cleanup(struct device *dev, void *data) ++static int regulator_late_cleanup(struct device *dev, void *data) + { + struct regulator_dev *rdev = dev_to_rdev(dev); + const struct regulator_ops *ops = rdev->desc->ops; +@@ -4501,18 +4501,9 @@ unlock: + return 0; + } + +-static int __init regulator_init_complete(void) ++static void regulator_init_complete_work_function(struct work_struct *work) + { + /* +- * Since DT doesn't provide an idiomatic mechanism for +- * enabling full constraints and since it's much more natural +- * with DT to provide them just assume that a DT enabled +- * system has full constraints. +- */ +- if (of_have_populated_dt()) +- has_full_constraints = true; +- +- /* + * Regulators may had failed to resolve their input supplies + * when were registered, either because the input supply was + * not registered yet or because its parent device was not +@@ -4529,6 +4520,35 @@ static int __init regulator_init_complet + */ + class_for_each_device(®ulator_class, NULL, NULL, + regulator_late_cleanup); ++} ++ ++static DECLARE_DELAYED_WORK(regulator_init_complete_work, ++ regulator_init_complete_work_function); ++ ++static int __init regulator_init_complete(void) ++{ ++ /* ++ * Since DT doesn't provide an idiomatic mechanism for ++ * enabling full constraints and since it's much more natural ++ * with DT to provide them just assume that a DT enabled ++ * system has full constraints. ++ */ ++ if (of_have_populated_dt()) ++ has_full_constraints = true; ++ ++ /* ++ * We punt completion for an arbitrary amount of time since ++ * systems like distros will load many drivers from userspace ++ * so consumers might not always be ready yet, this is ++ * particularly an issue with laptops where this might bounce ++ * the display off then on. Ideally we'd get a notification ++ * from userspace when this happens but we don't so just wait ++ * a bit and hope we waited long enough. It'd be better if ++ * we'd only do this on systems that need it, and a kernel ++ * command line option might be useful. ++ */ ++ schedule_delayed_work(®ulator_init_complete_work, ++ msecs_to_jiffies(30000)); + + return 0; + } diff --git a/queue-4.9/series b/queue-4.9/series index 5aeb59db197..598494ad1fb 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -105,3 +105,9 @@ parisc-disable-hp-hsc-pci-cards-to-prevent-kernel-crash.patch kvm-x86-always-stop-emulation-on-page-fault.patch kvm-x86-set-ctxt-have_exception-in-x86_decode_insn.patch kvm-x86-manually-calculate-reserved-bits-when-loading-pdptrs.patch +media-sn9c20x-add-msi-ms-1039-laptop-to-flip_dmi_table.patch +asoc-intel-nhlt-fix-debug-print-format.patch +asoc-intel-fix-use-of-potentially-uninitialized-variable.patch +arm-zynq-use-memcpy_toio-instead-of-memcpy-on-smp-bring-up.patch +alarmtimer-use-eopnotsupp-instead-of-enotsupp.patch +regulator-defer-init-completion-for-a-while-after-late_initcall.patch