linux-kernel - Re: [PATCH 1/1] usb: pd: fix the SenderResponseTimer conform to specification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025010756-parlor-twirl-0803@gregkh>
Date: Tue, 7 Jan 2025 11:35:28 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Jos Wang <joswang1221@...il.com>
Cc: heikki.krogerus@...ux.intel.com, dmitry.baryshkov@...aro.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jos Wang <joswang@...ovo.com>, stable@...r.kernel.org
Subject: Re: [PATCH 1/1] usb: pd: fix the SenderResponseTimer conform to
 specification

On Mon, Jan 06, 2025 at 09:25:17PM +0800, Jos Wang wrote:
> On Sun, Jan 5, 2025 at 9:00 PM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Sun, Jan 05, 2025 at 08:52:51PM +0800, joswang wrote:
> > > From: Jos Wang <joswang@...ovo.com>
> > >
> > > 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
> >
> > Please put urls on one line so that they can be linked to correctly.
> >
> 
> OK，Thanks
> 
> > > 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
> > >
> > > Set the SenderResponseTimer timeout to 27ms to meet the PD2
> > > and PD3 mode requirements.
> > >
> > > Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Jos Wang <joswang@...ovo.com>
> > > ---
> > >  include/linux/usb/pd.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
> > > index 3068c3084eb6..99ca49bbf376 100644
> > > --- a/include/linux/usb/pd.h
> > > +++ b/include/linux/usb/pd.h
> > > @@ -475,7 +475,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 */
> >
> > Why 27 and not 30?  The comment seems odd here, right?
> >
> 
> 1、As mentioned in the commit message, "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. Since it takes
> time for the tcpm framework layer to initiate a Hard Reset (writing
> the PD PHY register through I2C operation), setting tSenderResponse to
> 30ms (PD2.0 spec max) will cause this test item to fail in PD2.0 mode.
> 
> 2、The comments here are indeed unreasonable, how about modifying it like this?
> +#define PD_T_SENDER_RESPONSE 27 /* PD2.0 spec 24ms -30ms, PD3.1 spec
> 27ms - 33ms, setting 27ms meets the requirements of PD2.0 and PD3.1.
> */

As it is, it needs to be changed to something else, so please pick
something that you would want to see if you were reading this code.

thanks,

greg k-h