linux-stable.git/drivers/ufs/core, branch linux-6.3.y

scsi: ufs: core: mcq: Fix the incorrect OCS value for the device command

2023-07-11T17:39:48+00:00

[ Upstream commit 0fef6bb730c490fcdc4347dbd21646d3ffe62cf5 ]

In MCQ mode, when a device command uses a hardware queue shared with other
commands, a race condition may occur in the following scenario:

 1. A device command is completed in CQx with CQE entry "e".

 2. The interrupt handler copies the "cqe" pointer to "hba->dev_cmd.cqe"
    and completes "hba->dev_cmd.complete".

 3. The "ufshcd_wait_for_dev_cmd()" function is awakened and retrieves the
    OCS value from "hba->dev_cmd.cqe".

However, there is a possibility that the CQE entry "e" will be overwritten
by newly completed commands in CQx, resulting in an incorrect OCS value
being received by "ufshcd_wait_for_dev_cmd()".

To avoid this race condition, the OCS value should be immediately copied to
the struct "lrb" of the device command. Then "ufshcd_wait_for_dev_cmd()"
can retrieve the OCS value from the struct "lrb".

Fixes: 57b1c0ef89ac ("scsi: ufs: core: mcq: Add support to allocate multiple queues")
Suggested-by: Can Guo 
Signed-off-by: Stanley Chu 
Link: https://lore.kernel.org/r/20230610021553.1213-2-powen.kao@mediatek.com
Tested-by: Po-Wen Kao 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: Remove a ufshcd_add_command_trace() call

2023-07-11T17:39:48+00:00

[ Upstream commit 72554035b9797e00e68cd866e6cefa7f0b2c6f76 ]

ufshcd_add_command_trace() traces SCSI commands. Remove a
ufshcd_add_command_trace() call from a code path that is not related to
SCSI commands.

Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20230531224050.25554-1-bvanassche@acm.org
Reviewed-by: Avri Altman 
Reviewed-by: Bean Huo 
Signed-off-by: Martin K. Petersen 
Stable-dep-of: 0fef6bb730c4 ("scsi: ufs: core: mcq: Fix the incorrect OCS value for the device command")
Signed-off-by: Sasha Levin

scsi: ufs: core: Fix handling of lrbp->cmd

2023-07-11T17:39:46+00:00

[ Upstream commit 549e91a9bbaa0ee480f59357868421a61d369770 ]

ufshcd_queuecommand() may be called two times in a row for a SCSI command
before it is completed. Hence make the following changes:

 - In the functions that submit a command, do not check the old value of
   lrbp->cmd nor clear lrbp->cmd in error paths.

 - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.

See also scsi_send_eh_cmnd().

This commit prevents that the following appears if a command times out:

WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8
Call trace:
 ufshcd_queuecommand+0x6f8/0x9a8
 scsi_send_eh_cmnd+0x2c0/0x960
 scsi_eh_test_devices+0x100/0x314
 scsi_eh_ready_devs+0xd90/0x114c
 scsi_error_handler+0x2b4/0xb70
 kthread+0x16c/0x1e0

Fixes: 5a0b0cb9bee7 ("[SCSI] ufs: Add support for sending NOP OUT UPIU")
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20230524203659.1394307-3-bvanassche@acm.org
Acked-by: Adrian Hunter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: Increase the START STOP UNIT timeout from one to ten seconds

2023-07-11T17:39:46+00:00

[ Upstream commit fe8637f7708c16765ecf4035813efbfdd2c9be10 ]

One UFS vendor asked to increase the UFS timeout from 1 s to 3 s.  Another
UFS vendor asked to increase the UFS timeout from 1 s to 10 s.  Hence this
patch that increases the UFS timeout to 10 s. This patch can cause the
total timeout to exceed 20 s, the Android shutdown timeout.  This is fine
since the loop around ufshcd_execute_start_stop() exists to deal with unit
attentions and because unit attentions are reported quickly.

Fixes: dcd5b7637c6d ("scsi: ufs: Reduce the START STOP UNIT timeout")
Fixes: 8f2c96420c6e ("scsi: ufs: core: Reduce the power mode change timeout")
Acked-by: Adrian Hunter 
Reviewed-by: Stanley Chu 
Reviewed-by: Bean Huo 
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20230524203659.1394307-2-bvanassche@acm.org
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: Declare ufshcd_{hold,release}() once

2023-07-11T17:39:46+00:00

[ Upstream commit 4b68b7f9c46d90c541d39c8b397a86ac0ca4c765 ]

ufshcd_hold() and ufshcd_release are declared twice: once in
drivers/ufs/core/ufshcd-priv.h and a second time in include/ufs/ufshcd.h.
Remove the declarations from ufshcd-priv.h.

Fixes: dd11376b9f1b ("scsi: ufs: Split the drivers/scsi/ufs directory")
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20230529202640.11883-5-bvanassche@acm.org
Reviewed-by: Adrian Hunter 
Reviewed-by: Keoseong Park 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: Fix MCQ nr_hw_queues

2023-06-09T08:48:08+00:00

[ Upstream commit 72a81bb0b6fc9b759ac0fdaca3ec5884a8b2f304 ]

Since MAXQ is 0-based value, add one to obtain number of hardware queues.

Signed-off-by: Po-Wen Kao 
Link: https://lore.kernel.org/r/20230504154454.26654-4-powen.kao@mediatek.com
Reviewed-by: Bean Huo 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Bart Van Assche 
Reviewed-by: Stanley Chu 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: Rename symbol sizeof_utp_transfer_cmd_desc()

2023-06-09T08:48:08+00:00

[ Upstream commit 06caeb536b2b21668efd2d6fa97c09461957b3a7 ]

Naming the functions after standard operators like sizeof() may cause
confusion. Rename it to ufshcd_get_ucd_size().

Signed-off-by: Po-Wen Kao 
Link: https://lore.kernel.org/r/20230504154454.26654-3-powen.kao@mediatek.com
Suggested-by: Manivannan Sadhasivam 
Reviewed-by: Stanley Chu 
Reviewed-by: Ziqi Chen 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: Fix MCQ tag calculation

2023-06-09T08:48:08+00:00

[ Upstream commit 5149452ca66289ef33d13897ee845a2f6f5b680f ]

The transfer command descriptor is allocated in ufshcd_memory_alloc() and
referenced by the transfer request descriptor with stride size
sizeof_utp_transfer_cmd_desc() instead of sizeof(struct
utp_transfer_cmd_desc).

Consequently, computing tag by address offset should also refer to the
same stride.

Signed-off-by: Po-Wen Kao 
Link: https://lore.kernel.org/r/20230504154454.26654-2-powen.kao@mediatek.com
Reviewed-by: Bart Van Assche 
Reviewed-by: Manivannan Sadhasivam 
Reviewed-by: Stanley Chu 
Reviewed-by: Ziqi Chen 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: Fix I/O hang that occurs when BKOPS fails in W-LUN suspend

2023-05-24T16:29:58+00:00

[ Upstream commit 1a7edd041f2d252f251523ba3f2eaead076a8f8d ]

Even when urgent BKOPS fails, the consumer will get stuck in runtime
suspend status. Like commit 1a5665fc8d7a ("scsi: ufs: core: WLUN suspend
SSU/enter hibern8 fail recovery"), trigger the error handler and return
-EBUSY to break the suspend.

Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun")
Signed-off-by: Keoseong Park 
Link: https://lore.kernel.org/r/20230425031721epcms2p5d4de65616478c967d466626e20c42a3a@epcms2p5
Reviewed-by: Avri Altman 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue

2023-05-17T12:01:36+00:00

[ Upstream commit 948afc69615167a3c82430f99bfd046332b89912 ]

When ufshcd_err_handler() is executed, CQ event interrupt can enter waiting
for the same lock. This can happen in ufshcd_handle_mcq_cq_events() and
also in ufs_mtk_mcq_intr(). The following warning message will be generated
when &hwq->cq_lock is used in IRQ context with IRQ enabled. Use
ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to
resolve the deadlock issue.

[name:lockdep&]WARNING: inconsistent lock state
[name:lockdep&]--------------------------------
[name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes:
  ffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}, at:
ufshcd_mcq_poll_cqe_lock+0x30/0xe0
[name:lockdep&]{IN-HARDIRQ-W} state was registered at:
  lock_acquire+0x17c/0x33c
  _raw_spin_lock+0x5c/0x7c
  ufshcd_mcq_poll_cqe_lock+0x30/0xe0
  ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod]
  __handle_irq_event_percpu+0x140/0x3ec
  handle_irq_event+0x50/0xd8
  handle_fasteoi_irq+0x148/0x2b0
  generic_handle_domain_irq+0x4c/0x6c
  gic_handle_irq+0x58/0x134
  call_on_irq_stack+0x40/0x74
  do_interrupt_handler+0x84/0xe4
  el1_interrupt+0x3c/0x78


Possible unsafe locking scenario:
       CPU0
       ----
  lock(&hwq->cq_lock);
  
    lock(&hwq->cq_lock);
  *** DEADLOCK ***
2 locks held by kworker/u16:4/260:

[name:lockdep&]
 stack backtrace:
CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S      W  OE
6.1.17-mainline-android14-2-g277223301adb #1
Workqueue: ufs_eh_wq_0 ufshcd_err_handler

 Call trace:
  dump_backtrace+0x10c/0x160
  show_stack+0x20/0x30
  dump_stack_lvl+0x98/0xd8
  dump_stack+0x20/0x60
  print_usage_bug+0x584/0x76c
  mark_lock_irq+0x488/0x510
  mark_lock+0x1ec/0x25c
  __lock_acquire+0x4d8/0xffc
  lock_acquire+0x17c/0x33c
  _raw_spin_lock+0x5c/0x7c
  ufshcd_mcq_poll_cqe_lock+0x30/0xe0
  ufshcd_poll+0x68/0x1b0
  ufshcd_transfer_req_compl+0x9c/0xc8
  ufshcd_err_handler+0x3bc/0xea0
  process_one_work+0x2f4/0x7e8
  worker_thread+0x234/0x450
  kthread+0x110/0x134
  ret_from_fork+0x10/0x20

Fixes: ed975065c31c ("scsi: ufs: core: mcq: Add completion support in poll")
Reviewed-by: Can Guo 
Reviewed-by: Stanley Chu 
Signed-off-by: Alice Chao 
Link: https://lore.kernel.org/r/20230424080400.8955-1-alice.chao@mediatek.com
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin