[PATCH 0/2] scsi: ufs: Add quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3

[PATCH 0/2] scsi: ufs: Add quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3

[Can Guo]

Add a quirk to support TX Equalization Training (EQTR) using Adapt L0L1L2L3
length which is larger than what is allowed by M-PHY spec ver 6.0.


Can Guo (2):
  scsi: ufs: core: Add a quirk for extended TX EQTR Adapt L0L1L2L3
    length
  scsi: ufs: ufs-qcom: Use quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3

 drivers/ufs/core/ufs-txeq.c | 8 ++++++--
 drivers/ufs/host/ufs-qcom.c | 3 +++
 include/ufs/ufshcd.h        | 7 +++++++
 3 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.34.1

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

[Can Guo]

Add a quirk to support TX Equalization Training (EQTR) using Adapt L0L1L2L3
length which is larger than what is allowed by M-PHY spec ver 6.0.

Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
 drivers/ufs/core/ufs-txeq.c | 8 ++++++--
 include/ufs/ufshcd.h        | 7 +++++++
 2 files changed, 13 insertions(+), 2 deletions(-)

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;
 		}
 
 		t_adapt_l0l1l2l3_local = adapt_cap_to_t_adapt_l0l1l2l3(adapt_l0l1l2l3_cap_local);
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index cfbc75d8df83..7a7c07636cf7 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -804,6 +804,13 @@ enum ufshcd_quirks {
 	 * delay after enabling VCC to ensure it's stable.
 	 */
 	UFSHCD_QUIRK_VCC_ON_DELAY			= 1 << 27,
+
+	/*
+	 * This quirk indicates that Host supports TX Equalization Training
+	 * (EQTR) using Adapt L0L1L2L3 length which is larger than what is
+	 * allowed by M-PHY spec ver 6.0.
+	 */
+	UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3	= 1 << 28,
 };
 
 enum ufshcd_caps {
-- 
2.34.1

[PATCH 2/2] scsi: ufs: ufs-qcom: Use quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3

[Can Guo]

Use UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3 for UFS Hosts
HW major version 0x7 & minor version 0x1.

Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
 drivers/ufs/host/ufs-qcom.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index bc037db46624..7b6957ef164b 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -1305,6 +1305,9 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
 	if (host->hw_ver.major > 0x3)
 		hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
 
+	if (host->hw_ver.major == 0x7 && host->hw_ver.minor == 0x1)
+		hba->quirks |= UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3;
+
 	if (drvdata && drvdata->quirks)
 		hba->quirks |= drvdata->quirks;
 }
-- 
2.34.1

Re: [PATCH 2/2] scsi: ufs: ufs-qcom: Use quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3

[Bart Van Assche]

On 5/1/26 3:16 PM, Can Guo wrote:
> +	if (host->hw_ver.major == 0x7 && host->hw_ver.minor == 0x1)
> +		hba->quirks |= UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3;
How about future versions of the Qualcomm controller? Will future 
versions support this feature?

Thanks,

Bart.

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

[Bart Van Assche]

On 5/1/26 3:16 PM, Can Guo wrote:
> Add a quirk to support TX Equalization Training (EQTR) using Adapt L0L1L2L3
> length which is larger than what is allowed by M-PHY spec ver 6.0.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>

Re: [PATCH 2/2] scsi: ufs: ufs-qcom: Use quirk EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3

[Can Guo]

Hi Bart,

On 5/4/2026 11:06 AM, Bart Van Assche wrote:
> On 5/1/26 3:16 PM, Can Guo wrote:
>> +    if (host->hw_ver.major == 0x7 && host->hw_ver.minor == 0x1)
>> +        hba->quirks |= 
>> UFSHCD_QUIRK_EXTENDED_TX_EQTR_ADAPT_LENGTH_L0L1L2L3;
> How about future versions of the Qualcomm controller? Will future 
> versions support this feature?
Minor version 0x2 might need the same Quirk, 0x3 might not. I don't have 
a real HW/silicon with minor
version 0x2 or 0x3 handy yet to verify, this is the best I can do as of 
today.

Thanks,
Can Guo.
>
> Thanks,
>
> Bart.

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

[Peter Wang (王信友)]

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?

Thanks
Peter

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

[Can Guo]

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!

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

[Peter Wang (王信友)]

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>