--- /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
+@@ -720,7 +720,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
+@@ -757,6 +757,9 @@ int __init acpi_aml_init(void)
+ goto err_exit;
+ }
+
++ 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 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
+@@ -223,9 +223,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;
+
+ if (get_edac_report_status() == EDAC_REPORTING_FORCE) {
--- /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
+@@ -268,6 +268,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 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
+@@ -2753,16 +2753,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 */
+ }
+@@ -2957,12 +2947,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 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
+@@ -336,7 +336,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
+@@ -141,7 +141,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 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
+@@ -30,9 +30,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
+@@ -47,15 +47,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--;
md-raid5-fix-oops-during-stripe-resizing.patch
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
+leds-bcm6328-bcm6358-use-devres-led-registering-function.patch
+fs-don-t-invalidate-page-buffers-in-block_write_full_page.patch
+nfs-fix-nfs_path-in-case-of-a-rename-retry.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
+acpi-cpufreq-honor-_psd-table-setting-on-new-amd-cpus.patch
+w1-mxc_w1-fix-timeout-resolution-problem-leading-to-bus-error.patch
--- /dev/null
+From c9723750a699c3bd465493ac2be8992b72ccb105 Mon Sep 17 00:00:00 2001
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Date: Wed, 30 Sep 2020 10:36:46 +0200
+Subject: w1: mxc_w1: Fix timeout resolution problem leading to bus error
+
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+
+commit c9723750a699c3bd465493ac2be8992b72ccb105 upstream.
+
+On my platform (i.MX53) bus access sometimes fails with
+ w1_search: max_slave_count 64 reached, will continue next search.
+
+The reason is the use of jiffies to implement a 200us timeout in
+mxc_w1_ds2_touch_bit().
+On some platforms the jiffies timer resolution is insufficient for this.
+
+Fix by replacing jiffies by ktime_get().
+
+For consistency apply the same change to the other use of jiffies in
+mxc_w1_ds2_reset_bus().
+
+Fixes: f80b2581a706 ("w1: mxc_w1: Optimize mxc_w1_ds2_touch_bit()")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Link: https://lore.kernel.org/r/1601455030-6607-1-git-send-email-martin.fuzzey@flowbird.group
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/w1/masters/mxc_w1.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/w1/masters/mxc_w1.c
++++ b/drivers/w1/masters/mxc_w1.c
+@@ -15,7 +15,7 @@
+ #include <linux/clk.h>
+ #include <linux/delay.h>
+ #include <linux/io.h>
+-#include <linux/jiffies.h>
++#include <linux/ktime.h>
+ #include <linux/module.h>
+ #include <linux/platform_device.h>
+
+@@ -48,12 +48,12 @@ struct mxc_w1_device {
+ static u8 mxc_w1_ds2_reset_bus(void *data)
+ {
+ struct mxc_w1_device *dev = data;
+- unsigned long timeout;
++ ktime_t timeout;
+
+ writeb(MXC_W1_CONTROL_RPP, dev->regs + MXC_W1_CONTROL);
+
+ /* Wait for reset sequence 511+512us, use 1500us for sure */
+- timeout = jiffies + usecs_to_jiffies(1500);
++ timeout = ktime_add_us(ktime_get(), 1500);
+
+ udelay(511 + 512);
+
+@@ -63,7 +63,7 @@ static u8 mxc_w1_ds2_reset_bus(void *dat
+ /* PST bit is valid after the RPP bit is self-cleared */
+ if (!(ctrl & MXC_W1_CONTROL_RPP))
+ return !(ctrl & MXC_W1_CONTROL_PST);
+- } while (time_is_after_jiffies(timeout));
++ } while (ktime_before(ktime_get(), timeout));
+
+ return 1;
+ }
+@@ -76,12 +76,12 @@ static u8 mxc_w1_ds2_reset_bus(void *dat
+ static u8 mxc_w1_ds2_touch_bit(void *data, u8 bit)
+ {
+ struct mxc_w1_device *dev = data;
+- unsigned long timeout;
++ ktime_t timeout;
+
+ writeb(MXC_W1_CONTROL_WR(bit), dev->regs + MXC_W1_CONTROL);
+
+ /* Wait for read/write bit (60us, Max 120us), use 200us for sure */
+- timeout = jiffies + usecs_to_jiffies(200);
++ timeout = ktime_add_us(ktime_get(), 200);
+
+ udelay(60);
+
+@@ -91,7 +91,7 @@ static u8 mxc_w1_ds2_touch_bit(void *dat
+ /* RDST bit is valid after the WR1/RD bit is self-cleared */
+ if (!(ctrl & MXC_W1_CONTROL_WR(bit)))
+ return !!(ctrl & MXC_W1_CONTROL_RDST);
+- } while (time_is_after_jiffies(timeout));
++ } while (ktime_before(ktime_get(), timeout));
+
+ return 0;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
