--- /dev/null
+From 21988a8e51479ceffe7b0568b170effabb708dfe Mon Sep 17 00:00:00 2001
+From: "dmitry.torokhov@gmail.com" <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 <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 <dmitry.torokhov@gmail.com>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 9a2e849fb6de471b82d19989a7944d3b7671793c Mon Sep 17 00:00:00 2001
+From: Hanjun Guo <guohanjun@huawei.com>
+Date: Fri, 18 Sep 2020 17:13:28 +0800
+Subject: ACPI: configfs: Add missing config_item_put() to fix refcount leak
+
+From: Hanjun Guo <guohanjun@huawei.com>
+
+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 <guohanjun@huawei.com>
+[ rjw: Subject edit ]
+Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 = {
--- /dev/null
+From 5368512abe08a28525d9b24abbfc2a72493e8dba Mon Sep 17 00:00:00 2001
+From: Wei Huang <wei.huang2@amd.com>
+Date: Sun, 18 Oct 2020 22:57:41 -0500
+Subject: acpi-cpufreq: Honor _PSD table setting on new AMD CPUs
+
+From: Wei Huang <wei.huang2@amd.com>
+
+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 <wei.huang2@amd.com>
+[ rjw: Subject edit ]
+Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 0fada277147ffc6d694aa32162f51198d4f10d94 Mon Sep 17 00:00:00 2001
+From: Jamie Iles <jamie@nuviainc.com>
+Date: Mon, 12 Oct 2020 14:04:46 +0100
+Subject: ACPI: debug: don't allow debugging when ACPI is disabled
+
+From: Jamie Iles <jamie@nuviainc.com>
+
+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 <guohanjun@huawei.com>
+Signed-off-by: Jamie Iles <jamie@nuviainc.com>
+Cc: 4.10+ <stable@vger.kernel.org> # 4.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From e0e9ce390d7bc6a705653d4a8aa4ea92c9a65e53 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+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 <rafael.j.wysocki@intel.com>
+
+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 <todd.e.brandt@linux.intel.com>
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.
--- /dev/null
+From 5e92442bb4121562231e6daf8a2d1306cb5f8805 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Mon, 5 Oct 2020 19:13:15 +0200
+Subject: ACPI: EC: PM: Flush EC work unconditionally after wakeup
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+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 <raymond.tan@intel.com>
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 7cecb47f55e00282f972a1e0b09136c8cd938221 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Sun, 27 Sep 2020 22:50:42 +0100
+Subject: ACPI / extlog: Check for RDMSR failure
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From b226faab4e7890bbbccdf794e8b94276414f9058 Mon Sep 17 00:00:00 2001
+From: Alex Hung <alex.hung@canonical.com>
+Date: Sun, 13 Sep 2020 16:34:03 -0600
+Subject: ACPI: video: use ACPI backlight for HP 635 Notebook
+
+From: Alex Hung <alex.hung@canonical.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Alex Hung <alex.hung@canonical.com>
+[ rjw: Changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
+ {
--- /dev/null
+From 6aaad58c872db062f7ea2761421ca748bd0931cc Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Mon, 17 Aug 2020 09:00:00 +0200
+Subject: extcon: ptn5150: Fix usage of atomic GPIO with sleeping GPIO chips
+
+From: Krzysztof Kozlowski <krzk@kernel.org>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Reviewed-by: Vijai Kumar K <vijaikumar.kanagarajan@gmail.com>
+Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+ }
+
--- /dev/null
+From 6dbf7bb555981fb5faf7b691e8f6169fc2b2e63b Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Fri, 4 Sep 2020 10:58:51 +0200
+Subject: fs: Don't invalidate page buffers in block_write_full_page()
+
+From: Jan Kara <jack@suse.cz>
+
+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 <yebin10@huawei.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+CC: stable@vger.kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
+ }
--- /dev/null
+From 2b52278150c49559a472f2d6dd66f6f3b405378e Mon Sep 17 00:00:00 2001
+From: Steve Foreman <foremans@google.com>
+Date: Fri, 2 Oct 2020 16:35:38 +0000
+Subject: hwmon: (pmbus/max34440) Fix OC fault limits
+
+From: Steve Foreman <foremans@google.com>
+
+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 <foremans@google.com>
+[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 <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From ff5c89d44453e7ad99502b04bf798a3fc32c758b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
+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 <marek.behun@nic.cz>
+
+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 <marek.behun@nic.cz>
+Cc: Álvaro Fernández Rojas <noltari@gmail.com>
+Cc: Kevin Cernekee <cernekee@gmail.com>
+Cc: Jaedon Shin <jaedon.shin@gmail.com>
+Signed-off-by: Pavel Machek <pavel@ucw.cz>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 93df48d37c3f03886d84831992926333e7810640 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <hdegoede@redhat.com>
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+ }
--- /dev/null
+From 247db73560bc3e5aef6db50c443c3c0db115bc93 Mon Sep 17 00:00:00 2001
+From: Ashish Sangwan <ashishsangwan2@gmail.com>
+Date: Mon, 5 Oct 2020 02:22:43 -0700
+Subject: NFS: fix nfs_path in case of a rename retry
+
+From: Ashish Sangwan <ashishsangwan2@gmail.com>
+
+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 <ashishsangwan2@gmail.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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--;
--- /dev/null
+From c6e331312ebfb52b7186e5d82d517d68b4d2f2d8 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+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 <lukas@wunner.de>
+
+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 <arthurborsboom@gmail.com>
+Reported-and-tested-by: matoro <matoro@airmail.cc>
+Reported-by: Aaron Zakhrov <aaron.zakhrov@gmail.com>
+Reported-by: Michal Rostecki <mrostecki@suse.com>
+Reported-by: Shai Coleman <git@shaicoleman.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
