From: Greg Kroah-Hartman Date: Fri, 17 May 2024 10:37:14 +0000 (+0200) Subject: 6.9-stable patches X-Git-Tag: v4.19.315~47 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2d07d76efbf929a862083ba5a1a3ef4040cc6025;p=thirdparty%2Fkernel%2Fstable-queue.git 6.9-stable patches added patches: bluetooth-btusb-fix-the-patch-for-mt7920-the-affected-to-mt7921.patch cpufreq-amd-pstate-fix-the-highest-frequency-issue-which-limits-performance.patch series wifi-iwlwifi-use-request_module_nowait.patch --- diff --git a/queue-6.9/bluetooth-btusb-fix-the-patch-for-mt7920-the-affected-to-mt7921.patch b/queue-6.9/bluetooth-btusb-fix-the-patch-for-mt7920-the-affected-to-mt7921.patch new file mode 100644 index 00000000000..1524a0a0456 --- /dev/null +++ b/queue-6.9/bluetooth-btusb-fix-the-patch-for-mt7920-the-affected-to-mt7921.patch @@ -0,0 +1,35 @@ +From 958cd6beab693f395ffe07814ef77d2b45e8b0fc Mon Sep 17 00:00:00 2001 +From: Peter Tsao +Date: Mon, 15 Apr 2024 22:19:22 +0800 +Subject: Bluetooth: btusb: Fix the patch for MT7920 the affected to MT7921 + +From: Peter Tsao + +commit 958cd6beab693f395ffe07814ef77d2b45e8b0fc upstream. + +Because both MT7920 and MT7921 use the same chip ID. +We use the 8th bit of fw_flavor to distingush MT7920. +The original patch made a mistake to check whole fw_flavor, +that makes the condition both true (dev_id == 0x7961 && fw_flavor), +and makes MT7921 flow wrong. + +In this patch, we correct the flow to get the 8th bit value for MT7920. +And the patch is verified pass with both MT7920 and MT7921. + +Signed-off-by: Peter Tsao +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bluetooth/btusb.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/bluetooth/btusb.c ++++ b/drivers/bluetooth/btusb.c +@@ -3118,6 +3118,7 @@ static int btusb_mtk_setup(struct hci_de + bt_dev_err(hdev, "Failed to get fw flavor (%d)", err); + return err; + } ++ fw_flavor = (fw_flavor & 0x00000080) >> 7; + } + + mediatek = hci_get_priv(hdev); diff --git a/queue-6.9/cpufreq-amd-pstate-fix-the-highest-frequency-issue-which-limits-performance.patch b/queue-6.9/cpufreq-amd-pstate-fix-the-highest-frequency-issue-which-limits-performance.patch new file mode 100644 index 00000000000..219cdc7953f --- /dev/null +++ b/queue-6.9/cpufreq-amd-pstate-fix-the-highest-frequency-issue-which-limits-performance.patch @@ -0,0 +1,92 @@ +From bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 Mon Sep 17 00:00:00 2001 +From: Perry Yuan +Date: Wed, 8 May 2024 13:47:03 +0800 +Subject: cpufreq: amd-pstate: fix the highest frequency issue which limits performance + +From: Perry Yuan + +commit bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 upstream. + +To address the performance drop issue, an optimization has been +implemented. The incorrect highest performance value previously set by the +low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID +ranging from 0x70 to 0x7F series has been identified as the cause. + +To resolve this, a check has been implemented to accurately determine the +CPU family and model ID. The correct highest performance value is now set +and the performance drop caused by the incorrect highest performance value +are eliminated. + +Before the fix, the highest frequency was set to 4200MHz, now it is set +to 4971MHz which is correct. + +CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ + 0 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 + 1 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 + 2 0 0 1 1:1:1:0 yes 4971.0000 400.0000 4865.8140 + 3 0 0 1 1:1:1:0 yes 4971.0000 400.0000 400.0000 + +Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759 +Signed-off-by: Perry Yuan +Co-developed-by: Mario Limonciello +Signed-off-by: Mario Limonciello +Tested-by: Gaha Bana +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/amd-pstate.c | 22 +++++++++++++++++++--- + 1 file changed, 19 insertions(+), 3 deletions(-) + +--- a/drivers/cpufreq/amd-pstate.c ++++ b/drivers/cpufreq/amd-pstate.c +@@ -50,7 +50,8 @@ + + #define AMD_PSTATE_TRANSITION_LATENCY 20000 + #define AMD_PSTATE_TRANSITION_DELAY 1000 +-#define AMD_PSTATE_PREFCORE_THRESHOLD 166 ++#define CPPC_HIGHEST_PERF_PERFORMANCE 196 ++#define CPPC_HIGHEST_PERF_DEFAULT 166 + + /* + * TODO: We need more time to fine tune processors with shared memory solution +@@ -290,6 +291,21 @@ static inline int amd_pstate_enable(bool + return static_call(amd_pstate_enable)(enable); + } + ++static u32 amd_pstate_highest_perf_set(struct amd_cpudata *cpudata) ++{ ++ struct cpuinfo_x86 *c = &cpu_data(0); ++ ++ /* ++ * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7f, ++ * the highest performance level is set to 196. ++ * https://bugzilla.kernel.org/show_bug.cgi?id=218759 ++ */ ++ if (c->x86 == 0x19 && (c->x86_model >= 0x70 && c->x86_model <= 0x7f)) ++ return CPPC_HIGHEST_PERF_PERFORMANCE; ++ ++ return CPPC_HIGHEST_PERF_DEFAULT; ++} ++ + static int pstate_init_perf(struct amd_cpudata *cpudata) + { + u64 cap1; +@@ -306,7 +322,7 @@ static int pstate_init_perf(struct amd_c + * the default max perf. + */ + if (cpudata->hw_prefcore) +- highest_perf = AMD_PSTATE_PREFCORE_THRESHOLD; ++ highest_perf = amd_pstate_highest_perf_set(cpudata); + else + highest_perf = AMD_CPPC_HIGHEST_PERF(cap1); + +@@ -330,7 +346,7 @@ static int cppc_init_perf(struct amd_cpu + return ret; + + if (cpudata->hw_prefcore) +- highest_perf = AMD_PSTATE_PREFCORE_THRESHOLD; ++ highest_perf = amd_pstate_highest_perf_set(cpudata); + else + highest_perf = cppc_perf.highest_perf; + diff --git a/queue-6.9/series b/queue-6.9/series new file mode 100644 index 00000000000..fa1d8a0a850 --- /dev/null +++ b/queue-6.9/series @@ -0,0 +1,3 @@ +bluetooth-btusb-fix-the-patch-for-mt7920-the-affected-to-mt7921.patch +wifi-iwlwifi-use-request_module_nowait.patch +cpufreq-amd-pstate-fix-the-highest-frequency-issue-which-limits-performance.patch diff --git a/queue-6.9/wifi-iwlwifi-use-request_module_nowait.patch b/queue-6.9/wifi-iwlwifi-use-request_module_nowait.patch new file mode 100644 index 00000000000..8a784dbefd9 --- /dev/null +++ b/queue-6.9/wifi-iwlwifi-use-request_module_nowait.patch @@ -0,0 +1,58 @@ +From 3d913719df14c28c4d3819e7e6d150760222bda4 Mon Sep 17 00:00:00 2001 +From: Ben Greear +Date: Tue, 30 Apr 2024 16:42:12 -0700 +Subject: wifi: iwlwifi: Use request_module_nowait + +From: Ben Greear + +commit 3d913719df14c28c4d3819e7e6d150760222bda4 upstream. + +This appears to work around a deadlock regression that came in +with the LED merge in 6.9. + +The deadlock happens on my system with 24 iwlwifi radios, so maybe +it something like all worker threads are busy and some work that needs +to complete cannot complete. + +Link: https://lore.kernel.org/linux-kernel/20240411070718.GD6194@google.com/ +Fixes: f5c31bcf604d ("Merge tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds") +Signed-off-by: Ben Greear +Link: https://msgid.link/20240430234212.2132958-1-greearb@candelatech.com +[also remove unnecessary "load_module" var and now-wrong comment] +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 10 +--------- + 1 file changed, 1 insertion(+), 9 deletions(-) + +--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c +@@ -1484,7 +1484,6 @@ static void iwl_req_fw_callback(const st + size_t trigger_tlv_sz[FW_DBG_TRIGGER_MAX]; + u32 api_ver; + int i; +- bool load_module = false; + bool usniffer_images = false; + bool failure = true; + +@@ -1732,19 +1731,12 @@ static void iwl_req_fw_callback(const st + goto out_unbind; + } + } else { +- load_module = true; ++ request_module_nowait("%s", op->name); + } + mutex_unlock(&iwlwifi_opmode_table_mtx); + + complete(&drv->request_firmware_complete); + +- /* +- * Load the module last so we don't block anything +- * else from proceeding if the module fails to load +- * or hangs loading. +- */ +- if (load_module) +- request_module("%s", op->name); + failure = false; + goto free; +