lkml.org 
[lkml]   [2026]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/2] scsi: ufs: core: Add a quirk for extended TX EQTR Adapt L0L1L2L3 length
Date
On Mon, 2026-05-04 at 20:55 +0800, Can Guo wrote:
> Hi Peter,
>
> Thanks for raising this; it is a good question. And I had spent quite
> some time
> on this one trying to make it as simple as possible...
>
> Firstly, it is intended. In TX EQTR flow, the host software programs
> a Adapt
> Length value to PA_TXADAPTLENGTH_EQTR and initiates TX EQTR
> procedure.
> With this quirk enabled, the host software is allowed (by Host HW) to
> continue
> TX EQTR even with a value which is above the spec max, so the Host
> software
> can attempt an extended (out-of-spec) value.
>
> Then the outcome is naturally determined by the peer device:
> 1. If the device tolerates the extended value, TX EQTR succeeds.
> 2. If the device does not, TX EQTR fails as part of normal EQTR
> behavior.
>
> So the quirk is intentionally host-only.
>
> A separate device quirk could be added, but for this path it would be
> redundant
> and would increase maintenance burden (for tracking a list of such
> devices) without
> changing the outcome.
>
> I hope I have answered your question and you can understand my
> considerations.
>
> Thanks,
> Can Guo.
>

Hi Can,

Thank you for the clarification. I have no further questions.

Reviewed-by: Peter Wang <peter.wang@mediatek.com>
\
 
 \ /
  Last update: 2026-05-05 07:49    [W:0.110 / U:2.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog