user/sven/linux.git, branch v6.6.81

Linux 6.6.81

2025-03-07T15:45:57Z

Link: https://lore.kernel.org/r/20250305174500.327985489@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: SeongJae Park Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Hardik Garg Link: https://lore.kernel.org/r/20250306151412.957725234@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Cancel RTC work during ufshcd_remove()

2025-03-07T15:45:57Z

commit 1695c4361d35b7bdadd7b34f99c9c07741e181e5 upstream. Currently, RTC work is only cancelled during __ufshcd_wl_suspend(). When ufshcd is removed in ufshcd_remove(), RTC work is not cancelled. Due to this, any further trigger of the RTC work after ufshcd_remove() would result in a NULL pointer dereference as below: Unable to handle kernel NULL pointer dereference at virtual address 00000000000002a4 Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c pm_runtime_get_if_active+0x24/0xb4 ufshcd_rtc_work+0x124/0x19c process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Since RTC work accesses the ufshcd internal structures, it should be cancelled when ufshcd is removed. So do that in ufshcd_remove(), as per the order in ufshcd_init(). Cc: stable@vger.kernel.org # 6.8 Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20241111-ufs_bug_fix-v1-1-45ad8b62f02e@linaro.org Reviewed-by: Peter Wang Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Start the RTC update work later

2025-03-07T15:45:57Z

commit 54c814c8b23bc7617be3d46abdb896937695dbfa upstream. The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20 Reported-by: Neil Armstrong Closes: https://lore.kernel.org/linux-scsi/0c0bc528-fdc2-4106-bc99-f23ae377f6f5@linaro.org/ Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Cc: Bean Huo Cc: stable@vger.kernel.org Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20241031212632.2799127-1-bvanassche@acm.org Reviewed-by: Peter Wang Reviewed-by: Bean Huo Tested-by: Neil Armstrong # on SM8650-HDK Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Fix another deadlock during RTC update

2025-03-07T15:45:57Z

commit cb7e509c4e0197f63717fee54fb41c4990ba8d3a upstream. If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock. Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Cc: stable@vger.kernel.org #6.11.x Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20241024015453.21684-1-peter.wang@mediatek.com Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

x86/microcode/AMD: Fix a -Wsometimes-uninitialized clang false positive

2025-03-07T15:45:57Z

commit 5343558a868e7e635b40baa2e46bf53df1a2d131 upstream. Initialize equiv_id in order to shut up: arch/x86/kernel/cpu/microcode/amd.c:714:6: warning: variable 'equiv_id' is \ used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (x86_family(bsp_cpuid_1_eax) < 0x17) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ because clang doesn't do interprocedural analysis for warnings to see that this variable won't be used uninitialized. Fixes: 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202407291815.gJBST0P3-lkp@intel.com/ Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Fix deadlock during RTC update

2025-03-07T15:45:56Z

commit 3911af778f208e5f49d43ce739332b91e26bc48e upstream. There is a deadlock when runtime suspend waits for the flush of RTC work, and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume. Here is deadlock backtrace: kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff __switch_to+0x1a8/0x2d4 __schedule+0x684/0xa98 schedule+0x48/0xc8 schedule_timeout+0x48/0x170 do_wait_for_common+0x108/0x1b0 wait_for_completion+0x44/0x60 __flush_work+0x39c/0x424 __cancel_work_sync+0xd8/0x208 cancel_delayed_work_sync+0x14/0x28 __ufshcd_wl_suspend+0x19c/0x480 ufshcd_wl_runtime_suspend+0x3c/0x1d4 scsi_runtime_suspend+0x78/0xc8 __rpm_callback+0x94/0x3e0 rpm_suspend+0x2d4/0x65c __pm_runtime_suspend+0x80/0x114 scsi_runtime_idle+0x38/0x6c rpm_idle+0x264/0x338 __pm_runtime_idle+0x80/0x110 ufshcd_rtc_work+0x128/0x1e4 process_one_work+0x26c/0x650 worker_thread+0x260/0x3d8 kthread+0x110/0x134 ret_from_fork+0x10/0x20 Skip updating RTC if RPM state is not RPM_ACTIVE. Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Cc: stable@vger.kernel.org # 6.9.x Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20240715063831.29792-1-peter.wang@mediatek.com Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

x86/microcode/AMD: Load only SHA256-checksummed patches

2025-03-07T15:45:56Z

commit 50cef76d5cb0e199cda19f026842560f6eedc4f7 upstream Load patches for which the driver carries a SHA256 checksum of the patch blob. This can be disabled by adding "microcode.amd_sha_check=off" on the kernel cmdline. But it is highly NOT recommended. Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman

x86/microcode/AMD: Add get_patch_level()

2025-03-07T15:45:56Z

commit 037e81fb9d2dfe7b31fd97e5f578854e38f09887 upstream Put the MSR_AMD64_PATCH_LEVEL reading of the current microcode revision the hw has, into a separate function. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20250211163648.30531-6-bp@kernel.org Signed-off-by: Greg Kroah-Hartman

x86/microcode/AMD: Get rid of the _load_microcode_amd() forward declaration

2025-03-07T15:45:56Z

commit b39c387164879eef71886fc93cee5ca7dd7bf500 upstream Simply move save_microcode_in_initrd() down. No functional changes. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20250211163648.30531-5-bp@kernel.org Signed-off-by: Greg Kroah-Hartman

x86/microcode/AMD: Merge early_apply_microcode() into its single callsite

2025-03-07T15:45:56Z

commit dc15675074dcfd79a2f10a6e39f96b0244961a01 upstream No functional changes. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20250211163648.30531-4-bp@kernel.org Signed-off-by: Greg Kroah-Hartman