linux-stable.git/drivers/ufs, branch v6.11

scsi: ufs: ufs-mediatek: Add UFSHCD_QUIRK_BROKEN_LSDBS_CAP

2024-08-29T01:29:20+00:00

MT8183 implements the UFSHCI 2.1 spec but reports a bogus value of 1 in
the reserved part for the Legacy Single Doorbell Support (LSDBS)
capability.

Set UFSHCD_QUIRK_BROKEN_LSDBS_CAP when MCQ support is explicitly
disabled, allowing the device to be properly registered.

Signed-off-by: Mary Guillemard 
Link: https://lore.kernel.org/r/20240818222442.44990-3-mary@mary.zone
Reviewed-by: Peter Wang 
Signed-off-by: Martin K. Petersen

scsi: ufs: qcom: Add UFSHCD_QUIRK_BROKEN_LSDBS_CAP for SM8550 SoC

2024-08-17T01:09:17+00:00

SM8550 SoC has the UFSHCI 4.0 compliant UFS controller and only supports
legacy single doorbell mode without MCQ. But due to a hardware bug, it
reports 1 in the 'Legacy Queue & Single Doorbell Support (LSDBS)' field of
the Controller Capabilities register. This field is supposed to read as 0
if legacy single doorbell mode is supported and 1 otherwise.

Starting with commit 0c60eb0cc320 ("scsi: ufs: core: Check LSDBS cap when
!mcq"), ufshcd driver is now relying on the LSDBS field to decide when to
use the legacy doorbell mode if MCQ is not supported. And this ends up
breaking UFS on SM8550:

ufshcd-qcom 1d84000.ufs: ufshcd_init: failed to initialize (legacy doorbell mode not supported)
ufshcd-qcom 1d84000.ufs: error -EINVAL: Initialization failed with error -22

So use the UFSHCD_QUIRK_BROKEN_LSDBS_CAP quirk for SM8550 SoC so that the
ufshcd driver could use legacy doorbell mode correctly.

Fixes: 0c60eb0cc320 ("scsi: ufs: core: Check LSDBS cap when !mcq")
Tested-by: Amit Pundir 
Reviewed-by: Bart Van Assche 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20240816-ufs-bug-fix-v3-2-e6fe0e18e2a3@linaro.org
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Add a quirk for handling broken LSDBS field in controller capabilities register

2024-08-17T01:09:17+00:00

'Legacy Queue & Single Doorbell Support (LSDBS)' field in the controller
capabilities register is supposed to report whether the legacy single
doorbell mode is supported in the controller or not. But some controllers
report '1' in this field which corresponds to 'LSDB not supported', but
they indeed support LSDB. So let's add a quirk to handle those controllers.

If the quirk is enabled by the controller driver, then LSDBS register field
will be ignored and legacy single doorbell mode is assumed to be enabled
always.

Tested-by: Amit Pundir 
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20240816-ufs-bug-fix-v3-1-e6fe0e18e2a3@linaro.org
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Fix hba->last_dme_cmd_tstamp timestamp updating logic

2024-08-02T01:59:00+00:00

The ufshcd_add_delay_before_dme_cmd() always introduces a delay of
MIN_DELAY_BEFORE_DME_CMDS_US between DME commands even when it's not
required. The delay is added when the UFS host controller supplies the
quirk UFSHCD_QUIRK_DELAY_BEFORE_DME_CMDS.

Fix the logic to update hba->last_dme_cmd_tstamp to ensure subsequent DME
commands have the correct delay in the range of 0 to
MIN_DELAY_BEFORE_DME_CMDS_US.

Update the timestamp at the end of the function to ensure it captures the
latest time after any necessary delay has been applied.

Signed-off-by: Vamshi Gajjela 
Link: https://lore.kernel.org/r/20240724135126.1786126-1-vamshigajjela@google.com
Fixes: cad2e03d8607 ("ufs: add support to allow non standard behaviours (quirks)")
Cc: stable@vger.kernel.org
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

Merge branch '6.11/scsi-queue' into 6.11/scsi-fixes

2024-07-30T01:46:16+00:00

Pull outstanding commits from 6.11 queue into fixes.

Signed-off-by: Martin K. Petersen

scsi: ufs: exynos: Don't resume FMP when crypto support is disabled

2024-07-23T00:52:15+00:00

If exynos_ufs_fmp_init() did not enable FMP support, then
exynos_ufs_fmp_resume() should not execute the FMP-related SMC calls.

Fixes: c96499fcb403 ("scsi: ufs: exynos: Add support for Flash Memory Protector (FMP)")
Signed-off-by: Eric Biggers 
Link: https://lore.kernel.org/r/20240721183840.209284-1-ebiggers@kernel.org
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Do not set link to OFF state while waking up from hibernation

2024-07-23T00:32:36+00:00

UFS link is just put into hibern8 state during the 'freeze' process of the
hibernation. Afterwards, the system may get powered down. But that doesn't
matter during wakeup. Because during wakeup from hibernation, UFS link is
again put into hibern8 state by the restore kernel and then the control is
handed over to the to image kernel.

So in both the places, UFS link is never turned OFF. But
ufshcd_system_restore() just assumes that the link will be in OFF state and
sets the link state accordingly. And this breaks hibernation wakeup:

[ 2445.371335] phy phy-1d87000.phy.3: phy_power_on was called before phy_init
[ 2445.427883] ufshcd-qcom 1d84000.ufshc: Controller enable failed
[ 2445.427890] ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
[ 2445.427906] ufs_device_wlun 0:0:0:49488: ufshcd_wl_resume failed: -5
[ 2445.427918] ufs_device_wlun 0:0:0:49488: PM: dpm_run_callback(): scsi_bus_restore returns -5
[ 2445.427973] ufs_device_wlun 0:0:0:49488: PM: failed to restore async: error -5

So fix the issue by removing the code that sets the link to OFF state.

Cc: Anjana Hari 
Cc: stable@vger.kernel.org # 6.3
Fixes: 88441a8d355d ("scsi: ufs: core: Add hibernation callbacks")
Signed-off-by: Manivannan Sadhasivam 
Link: https://lore.kernel.org/r/20240718170659.201647-1-manivannan.sadhasivam@linaro.org
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2024-07-19T17:56:58+00:00

Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (ufs, lpfc, qla2xxx, mpi3mr) plus some
  misc small fixes.

  The only core changes are to both bsg and scsi to pass in the device
  instead of setting it afterwards as q->queuedata, so no functional
  change"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (69 commits)
  scsi: aha152x: Use DECLARE_COMPLETION_ONSTACK for non-constant completion
  scsi: qla2xxx: Convert comma to semicolon
  scsi: qla2xxx: Update version to 10.02.09.300-k
  scsi: qla2xxx: Use QP lock to search for bsg
  scsi: qla2xxx: Reduce fabric scan duplicate code
  scsi: qla2xxx: Fix optrom version displayed in FDMI
  scsi: qla2xxx: During vport delete send async logout explicitly
  scsi: qla2xxx: Complete command early within lock
  scsi: qla2xxx: Fix flash read failure
  scsi: qla2xxx: Return ENOBUFS if sg_cnt is more than one for ELS cmds
  scsi: qla2xxx: Fix for possible memory corruption
  scsi: qla2xxx: validate nvme_local_port correctly
  scsi: qla2xxx: Unable to act on RSCN for port online
  scsi: ufs: exynos: Add support for Flash Memory Protector (FMP)
  scsi: ufs: core: Add UFSHCD_QUIRK_KEYS_IN_PRDT
  scsi: ufs: core: Add fill_crypto_prdt variant op
  scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_CRYPTO_ENABLE
  scsi: ufs: core: fold ufshcd_clear_keyslot() into its caller
  scsi: ufs: core: Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE
  scsi: ufs: mcq: Make .get_hba_mac() optional
  ...

scsi: ufs: core: Fix deadlock during RTC update

2024-07-16T02:57:16+00:00

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

scsi: ufs: core: Bypass quick recovery if force reset is needed

2024-07-16T02:53:27+00:00

If force_reset is true, bypass quick recovery.  This will shorten error
recovery time.

Signed-off-by: Peter Wang 
Link: https://lore.kernel.org/r/20240712094506.11284-1-peter.wang@mediatek.com
Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen