On Sun, Dec 22, 2024 at 9:14 PM Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > On Sun, Dec 22, 2024 at 06:52:39PM +0800, joswang wrote: > > From: Jos Wang <joswang@xxxxxxxxxx> > > > > 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. > The patch is divided into patch1 (fix the timeout to follow the standard), patch2 (Make timeout depend on the PD version) and patch3 (Make timeouts configurable via DT). Do you suggest that these three patches should be submitted as V3 version, or patch1 and patch2 should be submitted separately? Please help to confirm, thank you. > > > > Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") > > Cc: stable@xxxxxxxxxxxxxxx > > Signed-off-by: Jos Wang <joswang@xxxxxxxxxx> > > --- > > v1 -> v2: > > - modify the commit message > > - patch 1/2 and patch 2/2 are placed in the same thread > > -- > With best wishes > Dmitry
