linux-kernel - Re: [PATCH v2, 2/3] usb: dwc3: core: add p3p2tranok quirk

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]

Date: Tue, 25 Jun 2024 21:31:28 +0800
From: joswang <joswang1221@...il.com>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>, 
	"conor+dt@...nel.org" <conor+dt@...nel.org>, 
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, 
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "balbi@...nel.org" <balbi@...nel.org>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, joswang <joswang@...ovo.com>
Subject: Re: [PATCH v2, 2/3] usb: dwc3: core: add p3p2tranok quirk

On Sat, Jun 22, 2024 at 8:05 AM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
>
> Sorry for the delay response regarding this.
>
> On Wed, Jun 19, 2024, joswang wrote:
> > Hi Thinh
> >
> > The workaround solution provided by your company for this issue is as follows:
> >   Workaround：if the phy support direct P3 to P2 transition，program
> > GUSB3PIPECTL.P3P2Tranok=1
> >
> > As the databook mentions:
> > This bit is used only for some non-Synopsys PHYs that cannot do LFPS in P3.
> > This bit is used by third-party SS PHY. It must be set to '0' for Synopsys PHY.
> >
> > For Synopsys PHY, if this bit is set to "1", will it cause unknown problems?
> > Please help confirm this, thank you!
> >
>
> That depends on what your use case and requirements are.
>
> I've reviewed this case. The impact to this issue is that power state
> change may take longer than expected. It may violate the PIPE spec, but
> functionally, at least for how linux drivers are handled, I'm not clear
> on how this will impact the typical user.
>
> Can you help clarify your use case and what does this resolve beside the
> fact that it workaround the increase latency/response time.
>
> Thanks,
> Thinh

Your company provides usage scenarios:
System software places the controller in low-power when there is no
traffic on the USB.
Subsequently, system software programs the controller to exit
low-power to resume traffic.

The method to reproduce the problem provided by your company:
1. Program the DWC_usb31 controller to operate in device mode of
operation. Program GUSB3PIPECTL.P3P2TranOK=0. To increase the
probability of hitting the problem run with a slower frequency for
suspend_clk (for example, 32 KHz and 160 KHz).
2. Place the link in U3 while ensuring that pipe_powerdown is driven to P3.
3. Program DWC_usb31 controller to exit U3. Ensure that for P0 ->P2
transition pipe_PhyStatus is returned immediately.
4. Program U3 exit from the remote link.
5. Program a D3 entry (pm_power_state_request=D3) at the same time
(from the device application) and observe if the D3 entry
acknowledgement (current_power_state_u3pmu=D3) takes longer than
expected (> 10 ms).

Currently, we do not have a real environment to verify this case, but
considering the Android GKI regulations, we need to submit patches to
Linux in advance. Based on the following workaround solution provided
by your company，since the hardware cannot be changed, we can only use
workaround 1 at present.
Workaround 1: If the PHY supports direct P3 to P2 transition, program
GUSB3PIPECTL.P3P2TranOK=1. However, note that as per PIPE4
Specification, direct transition from P3 to P2 is illegal.
Workaround 2: Delay the pipe_PhyStatus assertion by an amount greater
than two suspend_clk durations at the input of the controller's PIPE
interface.

We have the following questions and hope you can help us confirm them.
Thank you!
1. This case seems to describe that the P3 to P2 power state change
takes a long time, that is, the DWC3_usb31 controller takes a long
time to exit the D3 state. Please help evaluate whether this problem
is perceived from the software perspective, such as whether there is a
problem in the xhci_suspend or xhci_resume process. If from the
software perspective, this case will not cause the xhci driver to
fail, then we may not deal with this problem.
2. If this case causes the above problem, for Synopsys PHY,
configuring GUSB3PIPECTL.P3P2TranOK=1 will cause other unknown
problems?