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]

Message-ID: <20240622000528.3keexfbetetkrxpy@synopsys.com>
Date: Sat, 22 Jun 2024 00:05:32 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: joswang <joswang1221@...il.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        "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

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