[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <000001dc57a7$661a8040$324f80c0$@samsung.com>
Date: Mon, 17 Nov 2025 18:48:59 +0900
From: "Seunghui Lee" <sh043.lee@...sung.com>
To: 'Peter Wang (王信友)'
<peter.wang@...iatek.com>, <beanhuo@...ron.com>, <avri.altman@....com>,
<storage.sec@...sung.com>, <linux-scsi@...r.kernel.org>,
<bvanassche@....org>, <linux-kernel@...r.kernel.org>,
<alim.akhtar@...sung.com>, <adrian.hunter@...el.com>,
<martin.petersen@...cle.com>
Subject: RE: [PATCH] UFS: Make TM command timeout configurable from host
side
> 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.
Powered by blists - more mailing lists