From: Greg Kroah-Hartman Date: Tue, 3 Nov 2020 12:05:11 +0000 (+0100) Subject: 5.9-stable patches X-Git-Tag: v4.14.204~39 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a664acec4329c77f8a17797e7cb360ba4c7ab23a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.9-stable patches added patches: acpi-button-fix-handling-lid-state-changes-when-input-device-closed.patch acpi-configfs-add-missing-config_item_put-to-fix-refcount-leak.patch acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch acpi-debug-don-t-allow-debugging-when-acpi-is-disabled.patch acpi-ec-pm-drop-ec_no_wakeup-check-from-acpi_ec_dispatch_gpe.patch acpi-ec-pm-flush-ec-work-unconditionally-after-wakeup.patch acpi-extlog-check-for-rdmsr-failure.patch acpi-video-use-acpi-backlight-for-hp-635-notebook.patch extcon-ptn5150-fix-usage-of-atomic-gpio-with-sleeping-gpio-chips.patch fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch hwmon-pmbus-max34440-fix-oc-fault-limits.patch leds-bcm6328-bcm6358-use-devres-led-registering-function.patch media-uvcvideo-fix-uvc_ctrl_fixup_xu_info-not-having-any-effect.patch nfs-fix-nfs_path-in-case-of-a-rename-retry.patch pci-acpi-whitelist-hotplug-ports-for-d3-if-power-managed-by-acpi.patch --- diff --git a/queue-5.9/acpi-button-fix-handling-lid-state-changes-when-input-device-closed.patch b/queue-5.9/acpi-button-fix-handling-lid-state-changes-when-input-device-closed.patch new file mode 100644 index 00000000000..7a09becc64d --- /dev/null +++ b/queue-5.9/acpi-button-fix-handling-lid-state-changes-when-input-device-closed.patch @@ -0,0 +1,88 @@ +From 21988a8e51479ceffe7b0568b170effabb708dfe Mon Sep 17 00:00:00 2001 +From: "dmitry.torokhov@gmail.com" +Date: Sun, 4 Oct 2020 22:11:25 -0700 +Subject: ACPI: button: fix handling lid state changes when input device closed + +From: dmitry.torokhov@gmail.com + +commit 21988a8e51479ceffe7b0568b170effabb708dfe upstream. + +The original intent of 84d3f6b76447 was to delay evaluating lid state until +all drivers have been loaded, with input device being opened from userspace +serving as a signal for this condition. Let's ensure that state updates +happen even if userspace closed (or in the future inhibited) input device. + +Note that if we go through suspend/resume cycle we assume the system has +been fully initialized even if LID input device has not been opened yet. + +This has a side-effect of fixing access to input->users outside of +input->mutex protections by the way of eliminating said accesses and using +driver private flag. + +Fixes: 84d3f6b76447 ("ACPI / button: Delay acpi_lid_initialize_state() until first user space open") +Signed-off-by: Dmitry Torokhov +Reviewed-by: Hans de Goede +Cc: 4.15+ # 4.15+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/button.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/drivers/acpi/button.c ++++ b/drivers/acpi/button.c +@@ -153,6 +153,7 @@ struct acpi_button { + int last_state; + ktime_t last_time; + bool suspended; ++ bool lid_state_initialized; + }; + + static struct acpi_device *lid_device; +@@ -383,6 +384,8 @@ static int acpi_lid_update_state(struct + + static void acpi_lid_initialize_state(struct acpi_device *device) + { ++ struct acpi_button *button = acpi_driver_data(device); ++ + switch (lid_init_state) { + case ACPI_BUTTON_LID_INIT_OPEN: + (void)acpi_lid_notify_state(device, 1); +@@ -394,13 +397,14 @@ static void acpi_lid_initialize_state(st + default: + break; + } ++ ++ button->lid_state_initialized = true; + } + + static void acpi_button_notify(struct acpi_device *device, u32 event) + { + struct acpi_button *button = acpi_driver_data(device); + struct input_dev *input; +- int users; + + switch (event) { + case ACPI_FIXED_HARDWARE_EVENT: +@@ -409,10 +413,7 @@ static void acpi_button_notify(struct ac + case ACPI_BUTTON_NOTIFY_STATUS: + input = button->input; + if (button->type == ACPI_BUTTON_TYPE_LID) { +- mutex_lock(&button->input->mutex); +- users = button->input->users; +- mutex_unlock(&button->input->mutex); +- if (users) ++ if (button->lid_state_initialized) + acpi_lid_update_state(device, true); + } else { + int keycode; +@@ -457,7 +458,7 @@ static int acpi_button_resume(struct dev + struct acpi_button *button = acpi_driver_data(device); + + button->suspended = false; +- if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) { ++ if (button->type == ACPI_BUTTON_TYPE_LID) { + button->last_state = !!acpi_lid_evaluate_state(device); + button->last_time = ktime_get(); + acpi_lid_initialize_state(device); diff --git a/queue-5.9/acpi-configfs-add-missing-config_item_put-to-fix-refcount-leak.patch b/queue-5.9/acpi-configfs-add-missing-config_item_put-to-fix-refcount-leak.patch new file mode 100644 index 00000000000..7d20f4743bd --- /dev/null +++ b/queue-5.9/acpi-configfs-add-missing-config_item_put-to-fix-refcount-leak.patch @@ -0,0 +1,33 @@ +From 9a2e849fb6de471b82d19989a7944d3b7671793c Mon Sep 17 00:00:00 2001 +From: Hanjun Guo +Date: Fri, 18 Sep 2020 17:13:28 +0800 +Subject: ACPI: configfs: Add missing config_item_put() to fix refcount leak + +From: Hanjun Guo + +commit 9a2e849fb6de471b82d19989a7944d3b7671793c upstream. + +config_item_put() should be called in the drop_item callback, to +decrement refcount for the config item. + +Fixes: 772bf1e2878ec ("ACPI: configfs: Unload SSDT on configfs entry removal") +Signed-off-by: Hanjun Guo +[ rjw: Subject edit ] +Cc: 4.13+ # 4.13+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/acpi_configfs.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/acpi/acpi_configfs.c ++++ b/drivers/acpi/acpi_configfs.c +@@ -228,6 +228,7 @@ static void acpi_table_drop_item(struct + + ACPI_INFO(("Host-directed Dynamic ACPI Table Unload")); + acpi_unload_table(table->index); ++ config_item_put(cfg); + } + + static struct configfs_group_operations acpi_table_group_ops = { diff --git a/queue-5.9/acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch b/queue-5.9/acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch new file mode 100644 index 00000000000..ab716c46144 --- /dev/null +++ b/queue-5.9/acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch @@ -0,0 +1,37 @@ +From 5368512abe08a28525d9b24abbfc2a72493e8dba Mon Sep 17 00:00:00 2001 +From: Wei Huang +Date: Sun, 18 Oct 2020 22:57:41 -0500 +Subject: acpi-cpufreq: Honor _PSD table setting on new AMD CPUs + +From: Wei Huang + +commit 5368512abe08a28525d9b24abbfc2a72493e8dba upstream. + +acpi-cpufreq has a old quirk that overrides the _PSD table supplied by +BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+) +now accurately reports the P-state dependency of CPU cores. Hence this +quirk needs to be fixed in order to support new CPUs' frequency control. + +Fixes: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs") +Signed-off-by: Wei Huang +[ rjw: Subject edit ] +Cc: 3.10+ # 3.10+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/acpi-cpufreq.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/cpufreq/acpi-cpufreq.c ++++ b/drivers/cpufreq/acpi-cpufreq.c +@@ -691,7 +691,8 @@ static int acpi_cpufreq_cpu_init(struct + cpumask_copy(policy->cpus, topology_core_cpumask(cpu)); + } + +- if (check_amd_hwpstate_cpu(cpu) && !acpi_pstate_strict) { ++ if (check_amd_hwpstate_cpu(cpu) && boot_cpu_data.x86 < 0x19 && ++ !acpi_pstate_strict) { + cpumask_clear(policy->cpus); + cpumask_set_cpu(cpu, policy->cpus); + cpumask_copy(data->freqdomain_cpus, diff --git a/queue-5.9/acpi-debug-don-t-allow-debugging-when-acpi-is-disabled.patch b/queue-5.9/acpi-debug-don-t-allow-debugging-when-acpi-is-disabled.patch new file mode 100644 index 00000000000..9726c98ccea --- /dev/null +++ b/queue-5.9/acpi-debug-don-t-allow-debugging-when-acpi-is-disabled.patch @@ -0,0 +1,68 @@ +From 0fada277147ffc6d694aa32162f51198d4f10d94 Mon Sep 17 00:00:00 2001 +From: Jamie Iles +Date: Mon, 12 Oct 2020 14:04:46 +0100 +Subject: ACPI: debug: don't allow debugging when ACPI is disabled + +From: Jamie Iles + +commit 0fada277147ffc6d694aa32162f51198d4f10d94 upstream. + +If ACPI is disabled then loading the acpi_dbg module will result in the +following splat when lock debugging is enabled. + + DEBUG_LOCKS_WARN_ON(lock->magic != lock) + WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:938 __mutex_lock+0xa10/0x1290 + Kernel panic - not syncing: panic_on_warn set ... + CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8+ #103 + Hardware name: linux,dummy-virt (DT) + Call trace: + dump_backtrace+0x0/0x4d8 + show_stack+0x34/0x48 + dump_stack+0x174/0x1f8 + panic+0x360/0x7a0 + __warn+0x244/0x2ec + report_bug+0x240/0x398 + bug_handler+0x50/0xc0 + call_break_hook+0x160/0x1d8 + brk_handler+0x30/0xc0 + do_debug_exception+0x184/0x340 + el1_dbg+0x48/0xb0 + el1_sync_handler+0x170/0x1c8 + el1_sync+0x80/0x100 + __mutex_lock+0xa10/0x1290 + mutex_lock_nested+0x6c/0xc0 + acpi_register_debugger+0x40/0x88 + acpi_aml_init+0xc4/0x114 + do_one_initcall+0x24c/0xb10 + kernel_init_freeable+0x690/0x728 + kernel_init+0x20/0x1e8 + ret_from_fork+0x10/0x18 + +This is because acpi_debugger.lock has not been initialized as +acpi_debugger_init() is not called when ACPI is disabled. Fail module +loading to avoid this and any subsequent problems that might arise by +trying to debug AML when ACPI is disabled. + +Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities") +Reviewed-by: Hanjun Guo +Signed-off-by: Jamie Iles +Cc: 4.10+ # 4.10+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/acpi_dbg.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/acpi/acpi_dbg.c ++++ b/drivers/acpi/acpi_dbg.c +@@ -749,6 +749,9 @@ static int __init acpi_aml_init(void) + { + int ret; + ++ if (acpi_disabled) ++ return -ENODEV; ++ + /* Initialize AML IO interface */ + mutex_init(&acpi_aml_io.lock); + init_waitqueue_head(&acpi_aml_io.wait); diff --git a/queue-5.9/acpi-ec-pm-drop-ec_no_wakeup-check-from-acpi_ec_dispatch_gpe.patch b/queue-5.9/acpi-ec-pm-drop-ec_no_wakeup-check-from-acpi_ec_dispatch_gpe.patch new file mode 100644 index 00000000000..3f1fba8799c --- /dev/null +++ b/queue-5.9/acpi-ec-pm-drop-ec_no_wakeup-check-from-acpi_ec_dispatch_gpe.patch @@ -0,0 +1,36 @@ +From e0e9ce390d7bc6a705653d4a8aa4ea92c9a65e53 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Mon, 5 Oct 2020 19:13:46 +0200 +Subject: ACPI: EC: PM: Drop ec_no_wakeup check from acpi_ec_dispatch_gpe() + +From: Rafael J. Wysocki + +commit e0e9ce390d7bc6a705653d4a8aa4ea92c9a65e53 upstream. + +It turns out that in some cases there are EC events to flush in +acpi_ec_dispatch_gpe() even though the ec_no_wakeup kernel parameter +is set and the EC GPE is disabled while sleeping, so drop the +ec_no_wakeup check that prevents those events from being processed +from acpi_ec_dispatch_gpe(). + +Reported-by: Todd Brandt +Cc: 5.4+ # 5.4+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/ec.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/acpi/ec.c ++++ b/drivers/acpi/ec.c +@@ -2011,9 +2011,6 @@ bool acpi_ec_dispatch_gpe(void) + if (acpi_any_gpe_status_set(first_ec->gpe)) + return true; + +- if (ec_no_wakeup) +- return false; +- + /* + * Dispatch the EC GPE in-band, but do not report wakeup in any case + * to allow the caller to process events properly after that. diff --git a/queue-5.9/acpi-ec-pm-flush-ec-work-unconditionally-after-wakeup.patch b/queue-5.9/acpi-ec-pm-flush-ec-work-unconditionally-after-wakeup.patch new file mode 100644 index 00000000000..e43580b2b44 --- /dev/null +++ b/queue-5.9/acpi-ec-pm-flush-ec-work-unconditionally-after-wakeup.patch @@ -0,0 +1,46 @@ +From 5e92442bb4121562231e6daf8a2d1306cb5f8805 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Mon, 5 Oct 2020 19:13:15 +0200 +Subject: ACPI: EC: PM: Flush EC work unconditionally after wakeup + +From: Rafael J. Wysocki + +commit 5e92442bb4121562231e6daf8a2d1306cb5f8805 upstream. + +Commit 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC +GPE is inactive") has been reported to cause some power button wakeup +events to be missed on some systems, so modify acpi_ec_dispatch_gpe() +to call acpi_ec_flush_work() unconditionally to effectively reverse +the changes made by that commit. + +Also note that the problem which prompted commit 607b9df63057 is not +reproducible any more on the affected machine. + +Fixes: 607b9df63057 ("ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive") +Reported-by: Raymond Tan +Cc: 5.4+ # 5.4+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/ec.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/acpi/ec.c ++++ b/drivers/acpi/ec.c +@@ -2019,12 +2019,11 @@ bool acpi_ec_dispatch_gpe(void) + * to allow the caller to process events properly after that. + */ + ret = acpi_dispatch_gpe(NULL, first_ec->gpe); +- if (ret == ACPI_INTERRUPT_HANDLED) { ++ if (ret == ACPI_INTERRUPT_HANDLED) + pm_pr_dbg("ACPI EC GPE dispatched\n"); + +- /* Flush the event and query workqueues. */ +- acpi_ec_flush_work(); +- } ++ /* Flush the event and query workqueues. */ ++ acpi_ec_flush_work(); + + return false; + } diff --git a/queue-5.9/acpi-extlog-check-for-rdmsr-failure.patch b/queue-5.9/acpi-extlog-check-for-rdmsr-failure.patch new file mode 100644 index 00000000000..6cecdf3c1e6 --- /dev/null +++ b/queue-5.9/acpi-extlog-check-for-rdmsr-failure.patch @@ -0,0 +1,42 @@ +From 7cecb47f55e00282f972a1e0b09136c8cd938221 Mon Sep 17 00:00:00 2001 +From: Ben Hutchings +Date: Sun, 27 Sep 2020 22:50:42 +0100 +Subject: ACPI / extlog: Check for RDMSR failure + +From: Ben Hutchings + +commit 7cecb47f55e00282f972a1e0b09136c8cd938221 upstream. + +extlog_init() uses rdmsrl() to read an MSR, which on older CPUs +provokes a error message at boot: + + unchecked MSR access error: RDMSR from 0x179 at rIP: 0xcd047307 (native_read_msr+0x7/0x40) + +Use rdmsrl_safe() instead, and return -ENODEV if it fails. + +Reported-by: jim@photojim.ca +References: https://bugs.debian.org/971058 +Cc: All applicable +Signed-off-by: Ben Hutchings +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/acpi_extlog.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/acpi/acpi_extlog.c ++++ b/drivers/acpi/acpi_extlog.c +@@ -222,9 +222,9 @@ static int __init extlog_init(void) + u64 cap; + int rc; + +- rdmsrl(MSR_IA32_MCG_CAP, cap); +- +- if (!(cap & MCG_ELOG_P) || !extlog_get_l1addr()) ++ if (rdmsrl_safe(MSR_IA32_MCG_CAP, &cap) || ++ !(cap & MCG_ELOG_P) || ++ !extlog_get_l1addr()) + return -ENODEV; + + rc = -EINVAL; diff --git a/queue-5.9/acpi-video-use-acpi-backlight-for-hp-635-notebook.patch b/queue-5.9/acpi-video-use-acpi-backlight-for-hp-635-notebook.patch new file mode 100644 index 00000000000..a705a93f0c9 --- /dev/null +++ b/queue-5.9/acpi-video-use-acpi-backlight-for-hp-635-notebook.patch @@ -0,0 +1,42 @@ +From b226faab4e7890bbbccdf794e8b94276414f9058 Mon Sep 17 00:00:00 2001 +From: Alex Hung +Date: Sun, 13 Sep 2020 16:34:03 -0600 +Subject: ACPI: video: use ACPI backlight for HP 635 Notebook + +From: Alex Hung + +commit b226faab4e7890bbbccdf794e8b94276414f9058 upstream. + +The default backlight interface is AMD's radeon_bl0 which does not +work on this system, so use the ACPI backlight interface on it +instead. + +BugLink: https://bugs.launchpad.net/bugs/1894667 +Cc: All applicable +Signed-off-by: Alex Hung +[ rjw: Changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/video_detect.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/acpi/video_detect.c ++++ b/drivers/acpi/video_detect.c +@@ -282,6 +282,15 @@ static const struct dmi_system_id video_ + DMI_MATCH(DMI_PRODUCT_NAME, "530U4E/540U4E"), + }, + }, ++ /* https://bugs.launchpad.net/bugs/1894667 */ ++ { ++ .callback = video_detect_force_video, ++ .ident = "HP 635 Notebook", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "HP 635 Notebook PC"), ++ }, ++ }, + + /* Non win8 machines which need native backlight nevertheless */ + { diff --git a/queue-5.9/extcon-ptn5150-fix-usage-of-atomic-gpio-with-sleeping-gpio-chips.patch b/queue-5.9/extcon-ptn5150-fix-usage-of-atomic-gpio-with-sleeping-gpio-chips.patch new file mode 100644 index 00000000000..dddb7d6a311 --- /dev/null +++ b/queue-5.9/extcon-ptn5150-fix-usage-of-atomic-gpio-with-sleeping-gpio-chips.patch @@ -0,0 +1,57 @@ +From 6aaad58c872db062f7ea2761421ca748bd0931cc Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 17 Aug 2020 09:00:00 +0200 +Subject: extcon: ptn5150: Fix usage of atomic GPIO with sleeping GPIO chips + +From: Krzysztof Kozlowski + +commit 6aaad58c872db062f7ea2761421ca748bd0931cc upstream. + +The driver uses atomic version of gpiod_set_value() without any real +reason. It is called in a workqueue under mutex so it could sleep +there. Changing it to "can_sleep" flavor allows to use the driver with +all GPIO chips. + +Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver") +Cc: +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Vijai Kumar K +Signed-off-by: Chanwoo Choi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/extcon/extcon-ptn5150.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/extcon/extcon-ptn5150.c ++++ b/drivers/extcon/extcon-ptn5150.c +@@ -127,7 +127,7 @@ static void ptn5150_irq_work(struct work + case PTN5150_DFP_ATTACHED: + extcon_set_state_sync(info->edev, + EXTCON_USB_HOST, false); +- gpiod_set_value(info->vbus_gpiod, 0); ++ gpiod_set_value_cansleep(info->vbus_gpiod, 0); + extcon_set_state_sync(info->edev, EXTCON_USB, + true); + break; +@@ -138,9 +138,9 @@ static void ptn5150_irq_work(struct work + PTN5150_REG_CC_VBUS_DETECTION_MASK) >> + PTN5150_REG_CC_VBUS_DETECTION_SHIFT); + if (vbus) +- gpiod_set_value(info->vbus_gpiod, 0); ++ gpiod_set_value_cansleep(info->vbus_gpiod, 0); + else +- gpiod_set_value(info->vbus_gpiod, 1); ++ gpiod_set_value_cansleep(info->vbus_gpiod, 1); + + extcon_set_state_sync(info->edev, + EXTCON_USB_HOST, true); +@@ -156,7 +156,7 @@ static void ptn5150_irq_work(struct work + EXTCON_USB_HOST, false); + extcon_set_state_sync(info->edev, + EXTCON_USB, false); +- gpiod_set_value(info->vbus_gpiod, 0); ++ gpiod_set_value_cansleep(info->vbus_gpiod, 0); + } + } + diff --git a/queue-5.9/fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch b/queue-5.9/fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch new file mode 100644 index 00000000000..a717f2e5774 --- /dev/null +++ b/queue-5.9/fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch @@ -0,0 +1,94 @@ +From 6dbf7bb555981fb5faf7b691e8f6169fc2b2e63b Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Fri, 4 Sep 2020 10:58:51 +0200 +Subject: fs: Don't invalidate page buffers in block_write_full_page() + +From: Jan Kara + +commit 6dbf7bb555981fb5faf7b691e8f6169fc2b2e63b upstream. + +If block_write_full_page() is called for a page that is beyond current +inode size, it will truncate page buffers for the page and return 0. +This logic has been added in 2.5.62 in commit 81eb69062588 ("fix ext3 +BUG due to race with truncate") in history.git tree to fix a problem +with ext3 in data=ordered mode. This particular problem doesn't exist +anymore because ext3 is long gone and ext4 handles ordered data +differently. Also normally buffers are invalidated by truncate code and +there's no need to specially handle this in ->writepage() code. + +This invalidation of page buffers in block_write_full_page() is causing +issues to filesystems (e.g. ext4 or ocfs2) when block device is shrunk +under filesystem's hands and metadata buffers get discarded while being +tracked by the journalling layer. Although it is obviously "not +supported" it can cause kernel crashes like: + +[ 7986.689400] BUG: unable to handle kernel NULL pointer dereference at ++0000000000000008 +[ 7986.697197] PGD 0 P4D 0 +[ 7986.699724] Oops: 0002 [#1] SMP PTI +[ 7986.703200] CPU: 4 PID: 203778 Comm: jbd2/dm-3-8 Kdump: loaded Tainted: G ++O --------- - - 4.18.0-147.5.0.5.h126.eulerosv2r9.x86_64 #1 +[ 7986.716438] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 1.57 08/11/2015 +[ 7986.723462] RIP: 0010:jbd2_journal_grab_journal_head+0x1b/0x40 [jbd2] +... +[ 7986.810150] Call Trace: +[ 7986.812595] __jbd2_journal_insert_checkpoint+0x23/0x70 [jbd2] +[ 7986.818408] jbd2_journal_commit_transaction+0x155f/0x1b60 [jbd2] +[ 7986.836467] kjournald2+0xbd/0x270 [jbd2] + +which is not great. The crash happens because bh->b_private is suddently +NULL although BH_JBD flag is still set (this is because +block_invalidatepage() cleared BH_Mapped flag and subsequent bh lookup +found buffer without BH_Mapped set, called init_page_buffers() which has +rewritten bh->b_private). So just remove the invalidation in +block_write_full_page(). + +Note that the buffer cache invalidation when block device changes size +is already careful to avoid similar problems by using +invalidate_mapping_pages() which skips busy buffers so it was only this +odd block_write_full_page() behavior that could tear down bdev buffers +under filesystem's hands. + +Reported-by: Ye Bin +Signed-off-by: Jan Kara +Reviewed-by: Christoph Hellwig +CC: stable@vger.kernel.org +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + fs/buffer.c | 16 ---------------- + 1 file changed, 16 deletions(-) + +--- a/fs/buffer.c ++++ b/fs/buffer.c +@@ -2771,16 +2771,6 @@ int nobh_writepage(struct page *page, ge + /* Is the page fully outside i_size? (truncate in progress) */ + offset = i_size & (PAGE_SIZE-1); + if (page->index >= end_index+1 || !offset) { +- /* +- * The page may have dirty, unmapped buffers. For example, +- * they may have been added in ext3_writepage(). Make them +- * freeable here, so the page does not leak. +- */ +-#if 0 +- /* Not really sure about this - do we need this ? */ +- if (page->mapping->a_ops->invalidatepage) +- page->mapping->a_ops->invalidatepage(page, offset); +-#endif + unlock_page(page); + return 0; /* don't care */ + } +@@ -2975,12 +2965,6 @@ int block_write_full_page(struct page *p + /* Is the page fully outside i_size? (truncate in progress) */ + offset = i_size & (PAGE_SIZE-1); + if (page->index >= end_index+1 || !offset) { +- /* +- * The page may have dirty, unmapped buffers. For example, +- * they may have been added in ext3_writepage(). Make them +- * freeable here, so the page does not leak. +- */ +- do_invalidatepage(page, 0, PAGE_SIZE); + unlock_page(page); + return 0; /* don't care */ + } diff --git a/queue-5.9/hwmon-pmbus-max34440-fix-oc-fault-limits.patch b/queue-5.9/hwmon-pmbus-max34440-fix-oc-fault-limits.patch new file mode 100644 index 00000000000..eb594ddf6ee --- /dev/null +++ b/queue-5.9/hwmon-pmbus-max34440-fix-oc-fault-limits.patch @@ -0,0 +1,69 @@ +From 2b52278150c49559a472f2d6dd66f6f3b405378e Mon Sep 17 00:00:00 2001 +From: Steve Foreman +Date: Fri, 2 Oct 2020 16:35:38 +0000 +Subject: hwmon: (pmbus/max34440) Fix OC fault limits + +From: Steve Foreman + +commit 2b52278150c49559a472f2d6dd66f6f3b405378e upstream. + +The max34* family have the IOUT_OC_WARN_LIMIT and IOUT_OC_CRIT_LIMIT +registers swapped. + +Cc: stable@vger.kernel.org +Signed-off-by: Steve Foreman +[groeck: Updated subject, use C comment style, tab after defines] +[groeck: Added missing break; statements (by alexandru.ardelean@analog.com)] +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/pmbus/max34440.c | 23 +++++++++++++++++++++++ + 1 file changed, 23 insertions(+) + +--- a/drivers/hwmon/pmbus/max34440.c ++++ b/drivers/hwmon/pmbus/max34440.c +@@ -31,6 +31,13 @@ enum chips { max34440, max34441, max3444 + #define MAX34440_STATUS_OT_FAULT BIT(5) + #define MAX34440_STATUS_OT_WARN BIT(6) + ++/* ++ * The whole max344* family have IOUT_OC_WARN_LIMIT and IOUT_OC_FAULT_LIMIT ++ * swapped from the standard pmbus spec addresses. ++ */ ++#define MAX34440_IOUT_OC_WARN_LIMIT 0x46 ++#define MAX34440_IOUT_OC_FAULT_LIMIT 0x4A ++ + #define MAX34451_MFR_CHANNEL_CONFIG 0xe4 + #define MAX34451_MFR_CHANNEL_CONFIG_SEL_MASK 0x3f + +@@ -49,6 +56,14 @@ static int max34440_read_word_data(struc + const struct max34440_data *data = to_max34440_data(info); + + switch (reg) { ++ case PMBUS_IOUT_OC_FAULT_LIMIT: ++ ret = pmbus_read_word_data(client, page, phase, ++ MAX34440_IOUT_OC_FAULT_LIMIT); ++ break; ++ case PMBUS_IOUT_OC_WARN_LIMIT: ++ ret = pmbus_read_word_data(client, page, phase, ++ MAX34440_IOUT_OC_WARN_LIMIT); ++ break; + case PMBUS_VIRT_READ_VOUT_MIN: + ret = pmbus_read_word_data(client, page, phase, + MAX34440_MFR_VOUT_MIN); +@@ -115,6 +130,14 @@ static int max34440_write_word_data(stru + int ret; + + switch (reg) { ++ case PMBUS_IOUT_OC_FAULT_LIMIT: ++ ret = pmbus_write_word_data(client, page, MAX34440_IOUT_OC_FAULT_LIMIT, ++ word); ++ break; ++ case PMBUS_IOUT_OC_WARN_LIMIT: ++ ret = pmbus_write_word_data(client, page, MAX34440_IOUT_OC_WARN_LIMIT, ++ word); ++ break; + case PMBUS_VIRT_RESET_POUT_HISTORY: + ret = pmbus_write_word_data(client, page, + MAX34446_MFR_POUT_PEAK, 0); diff --git a/queue-5.9/leds-bcm6328-bcm6358-use-devres-led-registering-function.patch b/queue-5.9/leds-bcm6328-bcm6358-use-devres-led-registering-function.patch new file mode 100644 index 00000000000..08e8893ebcf --- /dev/null +++ b/queue-5.9/leds-bcm6328-bcm6358-use-devres-led-registering-function.patch @@ -0,0 +1,53 @@ +From ff5c89d44453e7ad99502b04bf798a3fc32c758b Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= +Date: Fri, 18 Sep 2020 00:32:58 +0200 +Subject: leds: bcm6328, bcm6358: use devres LED registering function +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marek Behún + +commit ff5c89d44453e7ad99502b04bf798a3fc32c758b upstream. + +These two drivers do not provide remove method and use devres for +allocation of other resources, yet they use led_classdev_register +instead of the devres variant, devm_led_classdev_register. + +Fix this. + +Signed-off-by: Marek Behún +Cc: Álvaro Fernández Rojas +Cc: Kevin Cernekee +Cc: Jaedon Shin +Signed-off-by: Pavel Machek +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/leds/leds-bcm6328.c | 2 +- + drivers/leds/leds-bcm6358.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/leds/leds-bcm6328.c ++++ b/drivers/leds/leds-bcm6328.c +@@ -383,7 +383,7 @@ static int bcm6328_led(struct device *de + led->cdev.brightness_set = bcm6328_led_set; + led->cdev.blink_set = bcm6328_blink_set; + +- rc = led_classdev_register(dev, &led->cdev); ++ rc = devm_led_classdev_register(dev, &led->cdev); + if (rc < 0) + return rc; + +--- a/drivers/leds/leds-bcm6358.c ++++ b/drivers/leds/leds-bcm6358.c +@@ -137,7 +137,7 @@ static int bcm6358_led(struct device *de + + led->cdev.brightness_set = bcm6358_led_set; + +- rc = led_classdev_register(dev, &led->cdev); ++ rc = devm_led_classdev_register(dev, &led->cdev); + if (rc < 0) + return rc; + diff --git a/queue-5.9/media-uvcvideo-fix-uvc_ctrl_fixup_xu_info-not-having-any-effect.patch b/queue-5.9/media-uvcvideo-fix-uvc_ctrl_fixup_xu_info-not-having-any-effect.patch new file mode 100644 index 00000000000..42305544390 --- /dev/null +++ b/queue-5.9/media-uvcvideo-fix-uvc_ctrl_fixup_xu_info-not-having-any-effect.patch @@ -0,0 +1,65 @@ +From 93df48d37c3f03886d84831992926333e7810640 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Tue, 28 Jul 2020 13:22:08 +0200 +Subject: media: uvcvideo: Fix uvc_ctrl_fixup_xu_info() not having any effect + +From: Hans de Goede + +commit 93df48d37c3f03886d84831992926333e7810640 upstream. + +uvc_ctrl_add_info() calls uvc_ctrl_get_flags() which will override +the fixed-up flags set by uvc_ctrl_fixup_xu_info(). + +uvc_ctrl_init_xu_ctrl() already calls uvc_ctrl_get_flags() before +calling uvc_ctrl_add_info(), so the uvc_ctrl_get_flags() call in +uvc_ctrl_add_info() is not necessary for xu ctrls. + +This commit moves the uvc_ctrl_get_flags() call for normal controls +from uvc_ctrl_add_info() to uvc_ctrl_init_ctrl(), so that we no longer +call uvc_ctrl_get_flags() twice for xu controls and so that we no longer +override the fixed-up flags set by uvc_ctrl_fixup_xu_info(). + +This fixes the xu motor controls not working properly on a Logitech +046d:08cc, and presumably also on the other Logitech models which have +a quirk for this in the uvc_ctrl_fixup_xu_info() function. + +Cc: stable@vger.kernel.org +Signed-off-by: Hans de Goede +Signed-off-by: Laurent Pinchart +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/usb/uvc/uvc_ctrl.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/media/usb/uvc/uvc_ctrl.c ++++ b/drivers/media/usb/uvc/uvc_ctrl.c +@@ -2033,13 +2033,6 @@ static int uvc_ctrl_add_info(struct uvc_ + goto done; + } + +- /* +- * Retrieve control flags from the device. Ignore errors and work with +- * default flag values from the uvc_ctrl array when the device doesn't +- * properly implement GET_INFO on standard controls. +- */ +- uvc_ctrl_get_flags(dev, ctrl, &ctrl->info); +- + ctrl->initialized = 1; + + uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s " +@@ -2262,6 +2255,13 @@ static void uvc_ctrl_init_ctrl(struct uv + if (uvc_entity_match_guid(ctrl->entity, info->entity) && + ctrl->index == info->index) { + uvc_ctrl_add_info(dev, ctrl, info); ++ /* ++ * Retrieve control flags from the device. Ignore errors ++ * and work with default flag values from the uvc_ctrl ++ * array when the device doesn't properly implement ++ * GET_INFO on standard controls. ++ */ ++ uvc_ctrl_get_flags(dev, ctrl, &ctrl->info); + break; + } + } diff --git a/queue-5.9/nfs-fix-nfs_path-in-case-of-a-rename-retry.patch b/queue-5.9/nfs-fix-nfs_path-in-case-of-a-rename-retry.patch new file mode 100644 index 00000000000..e6ef01e4a4d --- /dev/null +++ b/queue-5.9/nfs-fix-nfs_path-in-case-of-a-rename-retry.patch @@ -0,0 +1,58 @@ +From 247db73560bc3e5aef6db50c443c3c0db115bc93 Mon Sep 17 00:00:00 2001 +From: Ashish Sangwan +Date: Mon, 5 Oct 2020 02:22:43 -0700 +Subject: NFS: fix nfs_path in case of a rename retry + +From: Ashish Sangwan + +commit 247db73560bc3e5aef6db50c443c3c0db115bc93 upstream. + +We are generating incorrect path in case of rename retry because +we are restarting from wrong dentry. We should restart from the +dentry which was received in the call to nfs_path. + +CC: stable@vger.kernel.org +Signed-off-by: Ashish Sangwan +Signed-off-by: Anna Schumaker +Signed-off-by: Greg Kroah-Hartman + +--- + fs/nfs/namespace.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/fs/nfs/namespace.c ++++ b/fs/nfs/namespace.c +@@ -32,9 +32,9 @@ int nfs_mountpoint_expiry_timeout = 500 + /* + * nfs_path - reconstruct the path given an arbitrary dentry + * @base - used to return pointer to the end of devname part of path +- * @dentry - pointer to dentry ++ * @dentry_in - pointer to dentry + * @buffer - result buffer +- * @buflen - length of buffer ++ * @buflen_in - length of buffer + * @flags - options (see below) + * + * Helper function for constructing the server pathname +@@ -49,15 +49,19 @@ int nfs_mountpoint_expiry_timeout = 500 + * the original device (export) name + * (if unset, the original name is returned verbatim) + */ +-char *nfs_path(char **p, struct dentry *dentry, char *buffer, ssize_t buflen, +- unsigned flags) ++char *nfs_path(char **p, struct dentry *dentry_in, char *buffer, ++ ssize_t buflen_in, unsigned flags) + { + char *end; + int namelen; + unsigned seq; + const char *base; ++ struct dentry *dentry; ++ ssize_t buflen; + + rename_retry: ++ buflen = buflen_in; ++ dentry = dentry_in; + end = buffer+buflen; + *--end = '\0'; + buflen--; diff --git a/queue-5.9/pci-acpi-whitelist-hotplug-ports-for-d3-if-power-managed-by-acpi.patch b/queue-5.9/pci-acpi-whitelist-hotplug-ports-for-d3-if-power-managed-by-acpi.patch new file mode 100644 index 00000000000..9625257a13b --- /dev/null +++ b/queue-5.9/pci-acpi-whitelist-hotplug-ports-for-d3-if-power-managed-by-acpi.patch @@ -0,0 +1,65 @@ +From c6e331312ebfb52b7186e5d82d517d68b4d2f2d8 Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Fri, 2 Oct 2020 07:10:12 +0200 +Subject: PCI/ACPI: Whitelist hotplug ports for D3 if power managed by ACPI + +From: Lukas Wunner + +commit c6e331312ebfb52b7186e5d82d517d68b4d2f2d8 upstream. + +Recent laptops with dual AMD GPUs fail to suspend the discrete GPU, thus +causing lockups on system sleep and high power consumption at runtime. +The discrete GPU would normally be suspended to D3cold by turning off +ACPI _PR3 Power Resources of the Root Port above the GPU. + +However on affected systems, the Root Port is hotplug-capable and +pci_bridge_d3_possible() only allows hotplug ports to go to D3 if they +belong to a Thunderbolt device or if the Root Port possesses a +"HotPlugSupportInD3" ACPI property. Neither is the case on affected +laptops. The reason for whitelisting only specific, known to work +hotplug ports for D3 is that there have been reports of SkyLake Xeon-SP +systems raising Hardware Error NMIs upon suspending their hotplug ports: +https://lore.kernel.org/linux-pci/20170503180426.GA4058@otc-nc-03/ + +But if a hotplug port is power manageable by ACPI (as can be detected +through presence of Power Resources and corresponding _PS0 and _PS3 +methods) then it ought to be safe to suspend it to D3. To this end, +amend acpi_pci_bridge_d3() to whitelist such ports for D3. + +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1222 +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1252 +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1304 +Reported-and-tested-by: Arthur Borsboom +Reported-and-tested-by: matoro +Reported-by: Aaron Zakhrov +Reported-by: Michal Rostecki +Reported-by: Shai Coleman +Signed-off-by: Lukas Wunner +Acked-by: Alex Deucher +Cc: 5.4+ # 5.4+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/pci-acpi.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/pci/pci-acpi.c ++++ b/drivers/pci/pci-acpi.c +@@ -944,6 +944,16 @@ static bool acpi_pci_bridge_d3(struct pc + if (!dev->is_hotplug_bridge) + return false; + ++ /* Assume D3 support if the bridge is power-manageable by ACPI. */ ++ adev = ACPI_COMPANION(&dev->dev); ++ if (!adev && !pci_dev_is_added(dev)) { ++ adev = acpi_pci_find_companion(&dev->dev); ++ ACPI_COMPANION_SET(&dev->dev, adev); ++ } ++ ++ if (adev && acpi_device_power_manageable(adev)) ++ return true; ++ + /* + * Look for a special _DSD property for the root port and if it + * is set we know the hierarchy behind it supports D3 just fine. diff --git a/queue-5.9/series b/queue-5.9/series index aa766cbc78c..1d0ea775af7 100644 --- a/queue-5.9/series +++ b/queue-5.9/series @@ -195,3 +195,18 @@ perf-x86-amd-ibs-don-t-include-randomized-bits-in-get_ibs_op_count.patch perf-x86-amd-ibs-fix-raw-sample-data-accumulation.patch spi-spi-mtk-nor-fix-timeout-calculation-overflow.patch spi-sprd-release-dma-channel-also-on-probe-deferral.patch +extcon-ptn5150-fix-usage-of-atomic-gpio-with-sleeping-gpio-chips.patch +leds-bcm6328-bcm6358-use-devres-led-registering-function.patch +hwmon-pmbus-max34440-fix-oc-fault-limits.patch +media-uvcvideo-fix-uvc_ctrl_fixup_xu_info-not-having-any-effect.patch +fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch +acpi-configfs-add-missing-config_item_put-to-fix-refcount-leak.patch +nfs-fix-nfs_path-in-case-of-a-rename-retry.patch +acpi-button-fix-handling-lid-state-changes-when-input-device-closed.patch +acpi-extlog-check-for-rdmsr-failure.patch +acpi-video-use-acpi-backlight-for-hp-635-notebook.patch +acpi-debug-don-t-allow-debugging-when-acpi-is-disabled.patch +pci-acpi-whitelist-hotplug-ports-for-d3-if-power-managed-by-acpi.patch +acpi-ec-pm-flush-ec-work-unconditionally-after-wakeup.patch +acpi-ec-pm-drop-ec_no_wakeup-check-from-acpi_ec_dispatch_gpe.patch +acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch