Currently, UFS driver uses hardcoded TM_CMD_TIMEOUT (100ms) for all
Task Management commands, which may not be optimal for different UFS
devices and use cases.

This patch adds a configurable tm_cmd_timeout field to ufs_hba structure
and uses it instead of the hardcoded constant. The default value remains
TM_CMD_TIMEOUT to maintain backward compatibility.

[   90.372004] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 9
[   90.372025] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: UPIU[9] - issue time 80324520 us
[   90.372037] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: UPIU[9] - complete time 0 us
[   90.372049] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: UPIU[9] - Transfer Request Descriptor phys@0x28120
[   90.372085] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: UPIU[9] - Request UPIU phys@0xb400
[   90.372121] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: UPIU[9] - Response UPIU phys@0xb600
[   90.372180] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: UPIU[9] - PRDT - 2 entries  phys@0xb800
[   90.372193] [1:  kworker/u16:1:   10] ufshcd-qcom 1d84000.ufshc: ufshcd_abort: skipping abort
[   90.514494] [0:      scsi_eh_0:  209] ufshcd-qcom 1d84000.ufshc: __ufshcd_issue_tm_cmd: task management cmd 0x08 timed-out

Signed-off-by: Seunghui Lee <sh043.lee@samsung.com>
---
 drivers/ufs/core/ufshcd.c | 3 ++-
 include/ufs/ufshcd.h      | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 9ca27de4767a..6099504ffc35 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -7252,7 +7252,7 @@ static int __ufshcd_issue_tm_cmd(struct ufs_hba *hba,
 
 	/* wait until the task management command is completed */
 	err = wait_for_completion_io_timeout(&wait,
-			msecs_to_jiffies(TM_CMD_TIMEOUT));
+			msecs_to_jiffies(hba->tm_cmd_timeout));
 	if (!err) {
 		ufshcd_add_tm_upiu_trace(hba, task_tag, UFS_TM_ERR);
 		dev_err(hba->dev, "%s: task management cmd 0x%.2x timed-out\n",
@@ -10565,6 +10565,7 @@ int ufshcd_alloc_host(struct device *dev, struct ufs_hba **hba_handle)
 	hba->dev = dev;
 	hba->dev_ref_clk_freq = REF_CLK_FREQ_INVAL;
 	hba->nop_out_timeout = NOP_OUT_TIMEOUT;
+	hba->tm_cmd_timeout = TM_CMD_TIMEOUT;
 	ufshcd_set_sg_entry_size(hba, sizeof(struct ufshcd_sg_entry));
 	INIT_LIST_HEAD(&hba->clk_list_head);
 	spin_lock_init(&hba->outstanding_lock);
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 9425cfd9d00e..aed792eb9e16 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -884,6 +884,7 @@ enum ufshcd_mcq_opr {
  * @dev_cmd: ufs device management command information
  * @last_dme_cmd_tstamp: time stamp of the last completed DME command
  * @nop_out_timeout: NOP OUT timeout value
+ * @tm_cmd_timeout: TM CMD timeout value
  * @dev_info: information about the UFS device
  * @auto_bkops_enabled: to track whether bkops is enabled in device
  * @vreg_info: UFS device voltage regulator information
@@ -1042,6 +1043,7 @@ struct ufs_hba {
 	struct ufs_dev_cmd dev_cmd;
 	ktime_t last_dme_cmd_tstamp;
 	int nop_out_timeout;
+	int tm_cmd_timeout;
 
 	/* Keeps information of the UFS device connected to this host */
 	struct ufs_dev_info dev_info;
-- 
2.43.0

On 11/5/25 5:26 PM, Seunghui Lee wrote:
> Currently, UFS driver uses hardcoded TM_CMD_TIMEOUT (100ms) for all
> Task Management commands, which may not be optimal for different UFS
> devices and use cases.

Reviewed-by: Bart Van Assche <bvanassche@acm.org>

On Thu, 2025-11-06 at 10:26 +0900, Seunghui Lee wrote:
> Currently, UFS driver uses hardcoded TM_CMD_TIMEOUT (100ms) for all
> Task Management commands, which may not be optimal for different UFS
> devices and use cases.
> 
> This patch adds a configurable tm_cmd_timeout field to ufs_hba
> structure
> and uses it instead of the hardcoded constant. The default value
> remains
> TM_CMD_TIMEOUT to maintain backward compatibility.

Hi Seunghui,

There should be another patch to add a device quirk that 
modifies the value of tm_cmd_timeout?
Otherwise, this patch doesn’t actually change anything.

Thanks.
Peter

> -----Original Message-----
> From: Peter Wang (王信友) <peter.wang@mediatek.com>
> Sent: Tuesday, November 11, 2025 11:46 AM
> 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 Thu, 2025-11-06 at 10:26 +0900, Seunghui Lee wrote:
> > Currently, UFS driver uses hardcoded TM_CMD_TIMEOUT (100ms) for all
> > Task Management commands, which may not be optimal for different UFS
> > devices and use cases.
> >
> > This patch adds a configurable tm_cmd_timeout field to ufs_hba
> > structure and uses it instead of the hardcoded constant. The default
> > value remains TM_CMD_TIMEOUT to maintain backward compatibility.
> 
> Hi Seunghui,
> 
> There should be another patch to add a device quirk that modifies the
> value of tm_cmd_timeout?
> Otherwise, this patch doesn’t actually change anything.
> 
> Thanks.
> Peter
> 

Thank you for your kind opinion.
As you know, it's not easy to modify default value.
Because it effects all devices.

Should I read the tm_cmd_timeout from dt property?
What do you think?

* drivers/ufs/host/ufhcd-pltfrm.c

static void ufshcd_init_tm_cmd_timeout(struct ufs_hba *hba)
{
        struct device *dev = hba->dev;
        int ret;

        ret = of_property_read_u32(dev->of_node, "tm_cmd_timeout",
                        &hba->tm_cmd_timeout);
        if (ret) {
                dev_dbg(hba->dev,
                                "%s: failed to read tm_cmd_timeout, ret=%d\n",
                                __func__, ret);
                hba->tm_cmd_timeout = TM_CMD_TIMEOUT;                                                                                                                                                             
        }
}

Thanks,
Seunghui Lee.

On Tue, 2025-11-11 at 17:44 +0900, Seunghui Lee wrote:
> 
> 
> Thank you for your kind opinion.
> As you know, it's not easy to modify default value.
> Because it effects all devices.
> 
> Should I read the tm_cmd_timeout from dt property?
> What do you think?
> 
> * drivers/ufs/host/ufhcd-pltfrm.c
> 
> static void ufshcd_init_tm_cmd_timeout(struct ufs_hba *hba)
> {
>         struct device *dev = hba->dev;
>         int ret;
> 
>         ret = of_property_read_u32(dev->of_node, "tm_cmd_timeout",
>                         &hba->tm_cmd_timeout);
>         if (ret) {
>                 dev_dbg(hba->dev,
>                                 "%s: failed to read tm_cmd_timeout,
> ret=%d\n",
>                                 __func__, ret);
>                 hba->tm_cmd_timeout = TM_CMD_TIMEOUT;
>         }
> }
> 
> Thanks,
> Seunghui Lee.
> 

Hi Seunghui,

It seems that there is no node in the DTS to describe the
UFS device. The UFS host node is not suitable, because the
timeout value depends on the UFS device itself.

Since you found that some devices may have TM command 
times exceeding 100ms, why not add a device quirk and change 
the timeout value only for those devices?

Alternatively, you could consider using a module parameter, 
similar to uic_cmd_timeout and dev_cmd_timeout.

Thanks.
Peter

On 11/11/25 1:03 AM, Peter Wang (王信友) wrote:
> It seems that there is no node in the DTS to describe the
> UFS device. The UFS host node is not suitable, because the
> timeout value depends on the UFS device itself.
> 
> Since you found that some devices may have TM command
> times exceeding 100ms, why not add a device quirk and change
> the timeout value only for those devices?
> 
> Alternatively, you could consider using a module parameter,
> similar to uic_cmd_timeout and dev_cmd_timeout.

Why a quirk? A quirk will select a single specific timeout. The approach
of this patch lets the host driver set the timeout. This seems more
flexible to me than introducing a new quirk. Additionally, I think this
is a better solution than a new kernel module parameter.

Thanks,

Bart.

On Tue, 2025-11-11 at 08:37 -0800, Bart Van Assche wrote:
> 
> Why a quirk? A quirk will select a single specific timeout. The
> approach
> of this patch lets the host driver set the timeout. This seems more
> flexible to me than introducing a new quirk. Additionally, I think
> this
> is a better solution than a new kernel module parameter.
> 
> Thanks,
> 
> Bart.

Hi Bart,

It is not reasonable because the timeout value does not depend
on the host, it depends on the device. It could set a large 
timoeut value for those devices.

By the way, this patch also doesn't change any host timeout 
value if you insist that the timeout value depends on the host.

Using a module parameter is a flexible method if the customer 
is using a device that may require an extended timeout value.
Moreover, this approach would help maintain consistency. 
Otherwise, with so many different timeouts (uic/dev/tm),
it would be quite chaotic if each is handled in a different way.

Thanks
Peter

On 11/11/25 6:58 PM, Peter Wang (王信友) wrote:
> Using a module parameter is a flexible method if the customer
> is using a device that may require an extended timeout value.

Introducing a new kernel module parameter for a timeout that depends on
the UFS device model doesn't sound ideal to me.

Can't we increase the default timeout (TM_CMD_TIMEOUT)? Increasing the 
default timeout shouldn't affect any configuration negatively, isn't it?

Thanks,

Bart.

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

On 11/13/25 2:08 AM, Peter Wang (王信友) wrote:
> 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.
Hi Peter,

Aborting different commands should happen concurrently rather than
sequentially. See also the queue_delayed_work() call in the SCSI core
scsi_abort_command() function:

queue_delayed_work(shost->tmf_work_q, &scmd->abort_work, HZ / 100);

Unfortunately the max_active argument is set to 1 in the call that 
creates tmf_work_q:

shost->tmf_work_q = alloc_workqueue("scsi_tmf_%d",
				WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_SYSFS,
				   1, shost->host_no);

Hannes, do you agree with increasing the max_active argument from 1 to
INT_MAX? I think the above code was introduced 12 years ago by commit
e494f6a72839 ("[SCSI] improved eh timeout handler").

Thanks,

Bart.

On Mon, 2025-11-17 at 08:40 -0800, Bart Van Assche wrote
> 
> Hannes, do you agree with increasing the max_active argument from 1
> to
> INT_MAX? I think the above code was introduced 12 years ago by commit
> e494f6a72839 ("[SCSI] improved eh timeout handler").
> 
> Thanks,
> 
> Bart.

Hi Bart,

I think we can change max_active, but using the default value of 0 
should be sufficient, according to workqueue.rst.

The maximum limit for ``@max_active`` is 2048 and the default value
used
when 0 is specified is 1024. These values are chosen sufficiently high
such that they are not the limiting factor while providing protection
in
runaway cases.

Thanks
Peter

> -----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) {

On 11/16/25 11:11 PM, Seunghui Lee wrote:
>   /* 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) {

There are no other SCSI drivers I know of that have a retry loop around
the code that submits task management functions. I propose to reduce the
retry count in this function from 100 to 1.

Thanks,

Bart.

On Mon, 2025-11-17 at 08:43 -0800, Bart Van Assche wrote:
> 
> There are no other SCSI drivers I know of that have a retry loop
> around
> the code that submits task management functions. I propose to reduce
> the
> retry count in this function from 100 to 1.
> 
> Thanks,
> 
> Bart.

Hi Bart and Seunghui,

Sorry, after thinking it through, under normal circumstances
it usually only loops once, so changing it to 30 is fine.
However, in extreme cases, it’s possible that after a 30-second 
timeout, the device just send a response, and at the same time, 
when the host receives the response, the IRQ is pending by system.
(other irq is executing or spin_lock_irq, etc)
So I suggest not changing this value, since it doesn’t affect 
the normal execution time. But in extreme cases, it could indeed 
fix an error.

Thanks
Peter

On 11/17/25 9:55 PM, Peter Wang (王信友) wrote:
> However, in extreme cases, it’s possible that after a 30-second
> timeout, the device just send a response, and at the same time,
> when the host receives the response, the IRQ is pending by system.
> (other irq is executing or spin_lock_irq, etc)

It is not clear to me how this could happen? If a response is not
received in time from the UFS device, an abort TMF is sent. If the
device does not respond to the abort TMF, the UFS device is reset
(ufshcd_device_reset() is called if ufshcd_abort_all() fails). This
prevents that a response can be received after the error handler has
finished, isn't it?

Thanks,

Bart.

On Tue, 2025-11-18 at 09:31 -0800, Bart Van Assche wrote:
> On 11/17/25 9:55 PM, Peter Wang (王信友) wrote:
> > However, in extreme cases, it’s possible that after a 30-second
> > timeout, the device just send a response, and at the same time,
> > when the host receives the response, the IRQ is pending by system.
> > (other irq is executing or spin_lock_irq, etc)
> 
> It is not clear to me how this could happen? If a response is not
> received in time from the UFS device, an abort TMF is sent. If the
> device does not respond to the abort TMF, the UFS device is reset
> (ufshcd_device_reset() is called if ufshcd_abort_all() fails). This
> prevents that a response can be received after the error handler has
> finished, isn't it?
> 
> Thanks,
> 
> Bart.

Hi Bart,

The UFS device might take 30 seconds to send read/write 
response, and at the same time, the host sends a TM command
to query this read/write task. In this case, host will receive
the device’s TM response: UPIU_TASK_MANAGEMENT_FUNC_COMPL.

However, if the IRQ is disabled when the read/write response 
arrives, the host may not be able to process the response in 
time. Therefore, we need this loop to wait until the host IRQ
is enabled and to clear the inflight command.

Thanks
Peter

On Mon, 2025-11-17 at 16:11 +0900, Seunghui Lee wrote:
> 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.
> 


Hi Seunghui,

Changing TM_CMD_TIMEOUT from 100ms to 300ms is okay for me.
The adjustment of the TM retry count from 100 to 30 is not 
significant, so it does not matter whether this change is 
made or not. Overall, this patch looks good to me.

However, the other TM clear timeout of 1 second has a much
greater impact:
ufshcd_wait_for_register(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL, 
    mask, ~mask, 1000, 1000);
Would you consider shortening this value as well?

Thanks
Peter



> 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) {
> 
> 
> 

> On Mon, 2025-11-17 at 16:11 +0900, Seunghui Lee wrote:
> > 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.
> >
> 
> 
> Hi Seunghui,
> 
> Changing TM_CMD_TIMEOUT from 100ms to 300ms is okay for me.
> The adjustment of the TM retry count from 100 to 30 is not significant, so
> it does not matter whether this change is made or not. Overall, this patch
> looks good to me.
> 

Thank you for your opinion.
I'll update the revision.

> However, the other TM clear timeout of 1 second has a much greater impact:
> ufshcd_wait_for_register(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL,
>     mask, ~mask, 1000, 1000);
> Would you consider shortening this value as well?
> 
> Thanks
> Peter
> 

Thank you for your additional comment.
By the way, in my humble opinion, it's not about tm cmd timeout,
but about host register.

If it must be changed, how much time do you think for it?
I think that it's handled by different modification.

Thanks,
Seunghui Lee.

On Mon, 2025-11-17 at 18:48 +0900, Seunghui Lee wrote:
> Thank you for your additional comment.
> By the way, in my humble opinion, it's not about tm cmd timeout,
> but about host register.
> 
> If it must be changed, how much time do you think for it?
> I think that it's handled by different modification.
> 
> Thanks,
> Seunghui Lee.
> 

Hi Seunghui,

Yes, it is about the host register. I don’t have any ideas about
this for now, but a reasonable value should be at the millisecond
level.
I agree that this is another topic, so let’s leave it as is for now.

Thanks
Peter

> -----Original Message-----
> From: Peter Wang (王信友) <peter.wang@mediatek.com>
> Sent: Wednesday, November 12, 2025 11:58 AM
> 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 Tue, 2025-11-11 at 08:37 -0800, Bart Van Assche wrote:
> >
> > Why a quirk? A quirk will select a single specific timeout. The
> > approach of this patch lets the host driver set the timeout. This
> > seems more flexible to me than introducing a new quirk. Additionally,
> > I think this is a better solution than a new kernel module parameter.
> >
> > Thanks,
> >
> > Bart.
> 
> Hi Bart,
> 
> It is not reasonable because the timeout value does not depend on the host,
> it depends on the device. It could set a large timoeut value for those
> devices.
> 
> By the way, this patch also doesn't change any host timeout value if you
> insist that the timeout value depends on the host.
> 
> Using a module parameter is a flexible method if the customer is using a
> device that may require an extended timeout value.
> Moreover, this approach would help maintain consistency.
> Otherwise, with so many different timeouts (uic/dev/tm), it would be quite
> chaotic if each is handled in a different way.
> 
> Thanks
> Peter

Hi Peter,

Currently, the modification is about changing it in the same way as nop_out_timeout.
The tm_cmd_timeout value is not read from the device.
Also, if the UFS can read the tm_cmd_timeout value and requires a longer timeout period than the specified value, dev quirks would also be acceptable.

However, for now, it seems fine to set it on the host.
When we checked on our side, it wasn't that the tm timeout value was insufficient for specific devices, but rather some vendors needed to increase it.
We plan to appropriately increase and use it. Also, since the current modification maintains the default value and allows an appropriate value to be adjusted according to each vendor, the current method also seems acceptable.

Thank you,
Seunghui Lee.

On Wed, 2025-11-12 at 17:49 +0900, Seunghui Lee wrote:
> 
> Hi Peter,
> 
> Currently, the modification is about changing it in the same way as
> nop_out_timeout.
> The tm_cmd_timeout value is not read from the device.
> Also, if the UFS can read the tm_cmd_timeout value and requires a
> longer timeout period than the specified value, dev quirks would also
> be acceptable.
> 
> However, for now, it seems fine to set it on the host.
> When we checked on our side, it wasn't that the tm timeout value was
> insufficient for specific devices, but rather some vendors needed to
> increase it.
> We plan to appropriately increase and use it. Also, since the current
> modification maintains the default value and allows an appropriate
> value to be adjusted according to each vendor, the current method
> also seems acceptable.
> 
> Thank you,
> Seunghui Lee.
> 

Hi Seunghui,

The nop_out_timeout value can be changed by the host, as shown here:
https://lore.kernel.org/all/20210831145317.26306-1-adrian.hunter@intel.com/
(hba->nop_out_timeout = 200;)

However, in this patch, no one sets tm_cmd_timeout, correct?
So, I am saying that this patch doesn’t actually change anything, 
because the timeout is still 100ms for all hosts.

Thanks
Peter