kernel/git/stable/linux-stable.git/drivers/ufs, branch linux-6.17.y

scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify

2025-12-18T12:59:47+00:00

[ Upstream commit b0ee72db9132bd19b1b80152b35e0cf6a6cbd9f2 ] This fixes the dme-reset failed when doing recovery. Because device reset is not enough, we could occasionally see the error below: ufshcd-rockchip 2a2d0000.ufs: uic cmd 0x14 with arg3 0x0 completion timeout ufshcd-rockchip 2a2d0000.ufs: dme-reset: error code -110 ufshcd-rockchip 2a2d0000.ufs: DME_RESET failed ufshcd-rockchip 2a2d0000.ufs: ufshcd_host_reset_and_restore: Host init failed -110 Fix this by resetting the controller on PRE_CHANGE stage of hce enable notify. Fixes: d3cbe455d6eb ("scsi: ufs: rockchip: Initial support for UFS") Signed-off-by: Shawn Lin Link: https://patch.msgid.link/1763009575-237552-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: core: fix incorrect buffer duplication in ufshcd_read_string_desc()

2025-12-18T12:59:38+00:00

[ Upstream commit d794b499f948801f54d67ddbc34a6eac5a6d150a ] The function ufshcd_read_string_desc() was duplicating memory starting from the beginning of struct uc_string_id, which included the length and type fields. As a result, the allocated buffer contained unwanted metadata in addition to the string itself. The correct behavior is to duplicate only the Unicode character array in the structure. Update the code so that only the actual string content is copied into the new buffer. Fixes: 5f57704dbcfe ("scsi: ufs: Use kmemdup in ufshcd_read_string_desc()") Reviewed-by: Avri Altman Reviewed-by: Bart Van Assche Signed-off-by: Bean Huo Link: https://patch.msgid.link/20251107230518.4060231-3-beanhuo@iokpp.de Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: core: Move the ufshcd_enable_intr() declaration

2025-12-18T12:59:23+00:00

[ Upstream commit b30006b5bec1dcba207bc42e7f7cd96a568acc27 ] ufshcd_enable_intr() is not exported and hence should not be declared in include/ufs/ufshcd.h. Fixes: 253757797973 ("scsi: ufs: core: Change MCQ interrupt enable flow") Signed-off-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20251014200118.3390839-7-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)

2025-12-01T10:46:05+00:00

[ Upstream commit 5127be409c6c3815c4a7d8f6d88043e44f9b9543 ] According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors. Signed-off-by: Nitin Rawat Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251012173828.9880-1-nitin.rawat@oss.qualcomm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: core: Fix invalid probe error return value

2025-11-13T20:37:48+00:00

commit a2b32bc1d9e359a9f90d0de6af16699facb10935 upstream. After DME Link Startup, the error return value is set to the MIPI UniPro GenericErrorCode which can be 0 (SUCCESS) or 1 (FAILURE). Upon failure during driver probe, the error code 1 is propagated back to the driver probe function which must return a negative value to indicate an error, but 1 is not negative, so the probe is considered to be successful even though it failed. Subsequently, removing the driver results in an oops because it is not in a valid state. This happens because none of the callers of ufshcd_init() expect a non-negative error code. Fix the return value and documentation to match actual usage. Fixes: 69f5eb78d4b0 ("scsi: ufs: core: Move the ufshcd_device_init(hba, true) call") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-5-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Add a quirk to suppress link_startup_again

2025-11-13T20:37:48+00:00

commit d34caa89a132cd69efc48361d4772251546fdb88 upstream. ufshcd_link_startup() has a facility (link_startup_again) to issue DME_LINKSTARTUP a 2nd time even though the 1st time was successful. Some older hardware benefits from that, however the behaviour is non-standard, and has been found to cause link startup to be unreliable for some Intel Alder Lake based host controllers. Add UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress link_startup_again, in preparation for setting the quirk for affected controllers. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-3-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL

2025-11-13T20:37:47+00:00

commit d968e99488c4b08259a324a89e4ed17bf36561a4 upstream. Link startup becomes unreliable for Intel Alder Lake based host controllers when a 2nd DME_LINKSTARTUP is issued unnecessarily. Employ UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress that from happening. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-4-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers

2025-11-13T20:37:47+00:00

commit bb44826c3bdbf1fa3957008a04908f45e5666463 upstream. Intel platforms with UFS, can support Suspend-to-Idle (S0ix) and Suspend-to-RAM (S3). For S0ix the link state should be HIBERNATE. For S3, state is lost, so the link state must be OFF. Driver policy, expressed by spm_lvl, can be 3 (link HIBERNATE, device SLEEP) for S0ix but must be changed to 5 (link OFF, device POWEROFF) for S3. Fix support for S0ix/S3 by switching spm_lvl as needed. During suspend ->prepare(), if the suspend target state is not Suspend-to-Idle, ensure the spm_lvl is at least 5 to ensure that resume will be possible from deep sleep states. During suspend ->complete(), restore the spm_lvl to its original value that is suitable for S0ix. This fix is first needed in Intel Alder Lake based controllers. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-2-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Revert "Make HID attributes visible"

2025-11-13T20:37:41+00:00

[ Upstream commit f838d624fd1183e07db86f3138bcd05fd7630a1e ] Patch "Make HID attributes visible" is needed for older kernel versions (e.g. 6.12) where ufs_get_device_desc() is called from ufshcd_probe_hba(). In these older kernel versions ufshcd_get_device_desc() may be called after the sysfs attributes have been added. In the upstream kernel however ufshcd_get_device_desc() is called before ufs_sysfs_add_nodes(). See also the ufshcd_device_params_init() call from ufshcd_init(). Hence, calling sysfs_update_group() is not necessary. See also commit 69f5eb78d4b0 ("scsi: ufs: core: Move the ufshcd_device_init(hba, true) call") in kernel v6.13. This patch fixes the following kernel warning: sysfs: cannot create duplicate filename '/devices/platform/3c2d0000.ufs/hid' Workqueue: async async_run_entry_fn Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0x104 dump_stack+0x18/0x3c sysfs_warn_dup+0x6c/0xc8 internal_create_group+0x1c8/0x504 sysfs_create_groups+0x38/0x9c ufs_sysfs_add_nodes+0x20/0x58 ufshcd_init+0x1114/0x134c ufshcd_pltfrm_init+0x728/0x7d8 ufs_google_probe+0x30/0x84 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa4/0x160 driver_probe_device+0x44/0x23c __device_attach_driver+0x15c/0x1f4 bus_for_each_drv+0x10c/0x168 __device_attach_async_helper+0x80/0xf8 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 ufshcd 3c2d0000.ufs: ufs_sysfs_add_nodes: sysfs groups creation failed (err = -17) Cc: Daniel Lee Cc: Peter Wang Cc: Bjorn Andersson Cc: Neil Armstrong Fixes: bb7663dec67b ("scsi: ufs: sysfs: Make HID attributes visible") Signed-off-by: Bart Van Assche Fixes: bb7663dec67b ("scsi: ufs: sysfs: Make HID attributes visible") Acked-by: Neil Armstrong Reviewed-by: Peter Wang Reviewed-by: Bjorn Andersson Link: https://patch.msgid.link/20251028222433.1108299-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: core: Fix a race condition related to the "hid" attribute group

2025-11-13T20:37:40+00:00

[ Upstream commit c74dc8ab47c1ec3927f63ca83b542c363249b3d8 ] ufs_sysfs_add_nodes() is called concurrently with ufs_get_device_desc(). This may cause the following code to be called before ufs_sysfs_add_nodes(): sysfs_update_group(&hba->dev->kobj, &ufs_sysfs_hid_group); If this happens, ufs_sysfs_add_nodes() triggers a kernel warning and fails. Fix this by calling ufs_sysfs_add_nodes() before SCSI LUNs are scanned since the sysfs_update_group() call happens from the context of thread that executes ufshcd_async_scan(). This patch fixes the following kernel warning: sysfs: cannot create duplicate filename '/devices/platform/3c2d0000.ufs/hid' Workqueue: async async_run_entry_fn Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0x104 dump_stack+0x18/0x3c sysfs_warn_dup+0x6c/0xc8 internal_create_group+0x1c8/0x504 sysfs_create_groups+0x38/0x9c ufs_sysfs_add_nodes+0x20/0x58 ufshcd_init+0x1114/0x134c ufshcd_pltfrm_init+0x728/0x7d8 ufs_google_probe+0x30/0x84 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa4/0x160 driver_probe_device+0x44/0x23c __device_attach_driver+0x15c/0x1f4 bus_for_each_drv+0x10c/0x168 __device_attach_async_helper+0x80/0xf8 async_run_entry_fn+0x4c/0x17c process_one_work+0x26c/0x65c worker_thread+0x33c/0x498 kthread+0x110/0x134 ret_from_fork+0x10/0x20 ufshcd 3c2d0000.ufs: ufs_sysfs_add_nodes: sysfs groups creation failed (err = -17) Cc: Daniel Lee Fixes: bb7663dec67b ("scsi: ufs: sysfs: Make HID attributes visible") Signed-off-by: Bart Van Assche Link: https://patch.msgid.link/20251014200118.3390839-2-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin