All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Seunghui Lee" <sh043.lee@samsung.com>
To: "'Peter Wang (王信友)'" <peter.wang@mediatek.com>,
	beanhuo@micron.com, avri.altman@wdc.com, storage.sec@samsung.com,
	linux-scsi@vger.kernel.org, bvanassche@acm.org,
	linux-kernel@vger.kernel.org, alim.akhtar@samsung.com,
	adrian.hunter@intel.com, martin.petersen@oracle.com
Subject: RE: [PATCH] UFS: Make TM command timeout configurable from host side
Date: Mon, 17 Nov 2025 16:11:19 +0900	[thread overview]
Message-ID: <000001dc5791$5f2ea880$1d8bf980$@samsung.com> (raw)
In-Reply-To: <b83804a8419f0e8cc1a6263144fbaf1583bab2ed.camel@mediatek.com>

> -----Original Message-----
> From: Peter Wang (王信友) <peter.wang@mediatek.com>
> Sent: Thursday, November 13, 2025 7:09 PM
> To: beanhuo@micron.com; sh043.lee@samsung.com; avri.altman@wdc.com;
> storage.sec@samsung.com; linux-scsi@vger.kernel.org; bvanassche@acm.org;
> linux-kernel@vger.kernel.org; alim.akhtar@samsung.com;
> adrian.hunter@intel.com; martin.petersen@oracle.com
> Subject: Re: [PATCH] UFS: Make TM command timeout configurable from host
> side
> 
> On Wed, 2025-11-12 at 08:51 -0800, Bart Van Assche wrote:
> >
> > Can't we increase the default timeout (TM_CMD_TIMEOUT)? Increasing the
> > default timeout shouldn't affect any configuration negatively, isn't
> > it?
> >
> 
> Hi Bart,
> 
> In the worst-case scenario (when the device is stuck), it may takes 1.1
> seconds to abort a single task. When the queue is full (64), there will be
> noticeable lag. Aborting all tasks can take over a minute, which is
> unacceptable regardless of whether TM_CMD_TIMEOUT is increased or not.
> Under normal conditions, it’s very unlikely to exceed 100ms. So I think
> directly modifying TM_CMD_TIMEOUT is also acceptable, but I suggest
> keeping it within 500ms.
> 
> However, the optimal solution is for the vendor to update the firmware,
> ensuring that TM command priority is set appropriately to prevent
> situations where it exceeds 100ms.
> 
> Thanks
> Peter

Hi Mr.Wang,

I understand your concerns about considering the worst-case scenario.
What about directly modifying TM_CMD_TIMEOUT (100ms -> 300ms) and
reducing the TM retry count from 100 to 30?

Please let me know your opinion.

Thank you,
Seunghui Lee.

--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -68,7 +68,7 @@ enum {
 #define ADVANCED_RPMB_REQ_TIMEOUT  3000 /* 3 seconds */
 
 /* Task management command timeout */
-#define TM_CMD_TIMEOUT 100 /* msecs */
+#define TM_CMD_TIMEOUT 300 /* msecs */
 
 /* maximum number of retries for a general UIC command  */
 #define UFS_UIC_COMMAND_RETRIES 3
@@ -7663,7 +7663,7 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag)
        int poll_cnt;
        u8 resp = 0xF;
 
-       for (poll_cnt = 100; poll_cnt; poll_cnt--) {
+       for (poll_cnt = 30; poll_cnt; poll_cnt--) {
                err = ufshcd_issue_tm_cmd(hba, lrbp->lun, lrbp->task_tag,
                                UFS_QUERY_TASK, &resp);
                if (!err && resp == UPIU_TASK_MANAGEMENT_FUNC_SUCCEEDED) {




  reply	other threads:[~2025-11-17  7:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20251106012702epcas1p28fdeed020ea44f18dcc751c283fbbcc2@epcas1p2.samsung.com>
2025-11-06  1:26 ` [PATCH] UFS: Make TM command timeout configurable from host side Seunghui Lee
2025-11-11  2:46   ` Peter Wang (王信友)
2025-11-11  8:44     ` Seunghui Lee
2025-11-11  9:03       ` Peter Wang (王信友)
2025-11-11 16:37         ` Bart Van Assche
2025-11-12  2:58           ` Peter Wang (王信友)
2025-11-12  8:49             ` Seunghui Lee
2025-11-12  9:42               ` Peter Wang (王信友)
2025-11-12 16:51             ` Bart Van Assche
2025-11-13 10:08               ` Peter Wang (王信友)
2025-11-17  7:11                 ` Seunghui Lee [this message]
2025-11-17  8:40                   ` Peter Wang (王信友)
2025-11-17  9:48                     ` Seunghui Lee
2025-11-18  5:48                       ` Peter Wang (王信友)
2025-11-17 16:43                   ` Bart Van Assche
2025-11-18  5:55                     ` Peter Wang (王信友)
2025-11-18 17:31                       ` Bart Van Assche
2025-11-19  9:20                         ` Peter Wang (王信友)
2025-11-17 16:40                 ` Bart Van Assche
2025-11-18  5:52                   ` Peter Wang (王信友)
2025-11-11 16:38   ` Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001dc5791$5f2ea880$1d8bf980$@samsung.com' \
    --to=sh043.lee@samsung.com \
    --cc=adrian.hunter@intel.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=peter.wang@mediatek.com \
    --cc=storage.sec@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.