Thread (11 messages) 11 messages, 3 authors, 2025-01-05

Re: [PATCH v2, 2/2] usb: typec: tcpm: fix the sender response time issue

From: Jos Wang <hidden>
Date: 2025-01-01 13:00:14
Also in: linux-usb, lkml, stable
Subsystem: the rest, usb subsystem · Maintainers: Linus Torvalds, Greg Kroah-Hartman

Hi, thanks for your help in reviewing the code, and happy new year to
you and your family!

For the first commit you mentioned (modification time is 27ms), I
understand that just modify the include/linux/usb/pd.h file:
diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
index d50098fb16b5..cd2cc535d21d 100644
--- a/include/linux/usb/pd.h
+++ b/include/linux/usb/pd.h
@@ -457,7 +457,7 @@ static inline unsigned int rdo_max_power(u32 rdo)
 #define PD_T_NO_RESPONSE       5000    /* 4.5 - 5.5 seconds */
 #define PD_T_DB_DETECT         10000   /* 10 - 15 seconds */
 #define PD_T_SEND_SOURCE_CAP   150     /* 100 - 200 ms */
-#define PD_T_SENDER_RESPONSE   60      /* 24 - 30 ms, relaxed */
+#define PD_T_SENDER_RESPONSE   27      /* 24 - 30 ms, relaxed */
 #define PD_T_RECEIVER_RESPONSE 15      /* 15ms max */
 #define PD_T_SOURCE_ACTIVITY   45
 #define PD_T_SINK_ACTIVITY     135
Is my understanding correct?


Thanks
Jos Wang

On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov
[off-list ref] wrote:
On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote:
quoted
From: Jos Wang <redacted>

According to the USB PD3 CTS specification
(https://usb.org/document-library/
usb-power-delivery-compliance-test-specification-0/
USB_PD3_CTS_Q4_2024_OR.zip), the requirements for
tSenderResponse are different in PD2 and PD3 modes, see
Table 19 Timing Table & Calculations. For PD2 mode, the
tSenderResponse min 24ms and max 30ms; for PD3 mode, the
tSenderResponse min 27ms and max 33ms.

For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test
item, after receiving the Source_Capabilities Message sent by
the UUT, the tester deliberately does not send a Request Message
in order to force the SenderResponse timer on the Source UUT to
timeout. The Tester checks that a Hard Reset is detected between
tSenderResponse min and max,the delay is between the last bit of
the GoodCRC Message EOP has been sent and the first bit of Hard
Reset SOP has been received. The current code does not distinguish
between PD2 and PD3 modes, and tSenderResponse defaults to 60ms.
This will cause this test item and the following tests to fail:
TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout
TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout

Considering factors such as SOC performance, i2c rate, and the speed
of PD chip sending data, "pd2-sender-response-time-ms" and
"pd3-sender-response-time-ms" DT time properties are added to allow
users to define platform timing. For values that have not been
explicitly defined in DT using this property, a default value of 27ms
for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set.
You have several different changes squashed into the same commit:
- Change the timeout from 60 ms to 27-30 ms (I'd recommend using 27 ms
  as it fits both 24-30 ms and 27-33 ms ranges,
- Make timeout depend on the PD version,
- Make timeouts configurable via DT.

Only the first item is a fix per se and only that change should be
considered for backporting. Please unsquash your changes into logical
commits.  Theoretically the second change can be thought about as a part
of the third change (making timeouts configurable) or of the fist change
(fix the timeout to follow the standard), but I'd suggest having three
separate commits.
quoted
Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS")
Cc: stable@vger.kernel.org
Signed-off-by: Jos Wang <redacted>
---
v1 -> v2:
- modify the commit message
- patch 1/2 and patch 2/2 are placed in the same thread
--
With best wishes
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help