Re: [PATCH 1/2] scsi: ufs: core: Add a quirk for extended TX EQTR Adapt L0L1L2L3 length

[Can Guo <can.guo@oss.qualcomm.com>]

On 5/4/2026 5:19 PM, Peter Wang (王信友) wrote:
>
> On Fri, 2026-05-01 at 06:16 -0700, Can Guo wrote:
> > 
> > diff --git a/drivers/ufs/core/ufs-txeq.c b/drivers/ufs/core/ufs-
> > txeq.c
> > index b2dc89124353..fe647450a7a1 100644
> > --- a/drivers/ufs/core/ufs-txeq.c
> > +++ b/drivers/ufs/core/ufs-txeq.c
> > @@ -740,7 +740,9 @@ static int
> > ufshcd_setup_tx_eqtr_adapt_length(struct ufs_hba *hba,
> >                 if (adapt_l0l1l2l3_cap_local >
> > ADAPT_L0L1L2L3_LENGTH_MAX) {
> >                         dev_err(hba->dev, "local
> > RX_HS_G%u_ADAPT_INITIAL_L0L1L2L3_CAP (0x%x) exceeds MAX\n",
> >                                 gear, adapt_l0l1l2l3_cap_local);
> > -                       return -EINVAL;
> > +
> > +                       if (!(hba->quirks &
> > UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3))
> > +                               return -EINVAL;
> >                 }
> > 
> >                 ret = ufshcd_dme_get(hba,
> > UIC_ARG_MIB(PA_PEERRXHSG6ADAPTINITIALL0L1L2L3),
> > @@ -751,7 +753,9 @@ static int
> > ufshcd_setup_tx_eqtr_adapt_length(struct ufs_hba *hba,
> >                 if (adapt_l0l1l2l3_cap_peer >
> > ADAPT_L0L1L2L3_LENGTH_MAX) {
> >                         dev_err(hba->dev, "peer
> > RX_HS_G%u_ADAPT_INITIAL_L0L1L2L3_CAP (0x%x) exceeds MAX\n",
> >                                 gear, adapt_l0l1l2l3_cap_peer);
> > -                       return -EINVAL;
> > +
> > +                       if (!(hba->quirks &
> > UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3))
> > +                               return -EINVAL;
> > 
>
> Hi Can,
>
> The quirk UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3
> is defined as a host quirk, but it appears to be used for the
> device (peer) in this context. Is this usage wrong or intended?
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.
>
> Thanks
> Peter
>
>
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!