linux-kernel - Re: [PATCH RFT 2/3] arm64: dts: qcom: glymur: Add USB related nodes

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] [day] [month] [year] [list]

Message-ID: <3b5685da-5178-46ec-b720-97e1ecd5310c@oss.qualcomm.com>
Date: Fri, 30 Jan 2026 16:11:34 -0800
From: Wesley Cheng <wesley.cheng@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Abel Vesa <abel.vesa@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        Pankaj Patil <pankaj.patil@....qualcomm.com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH RFT 2/3] arm64: dts: qcom: glymur: Add USB related nodes



On 1/28/2026 1:53 AM, Konrad Dybcio wrote:
> On 1/27/26 11:26 PM, Wesley Cheng wrote:
>>
>>
>> On 1/27/2026 3:46 AM, Konrad Dybcio wrote:
>>> On 1/27/26 12:41 PM, Abel Vesa wrote:
>>>> On 26-01-13 14:13:32, Konrad Dybcio wrote:
>>>>> On 1/13/26 1:33 PM, Abel Vesa wrote:
>>>>>> From: Wesley Cheng <wesley.cheng@....qualcomm.com>
>>>>>>
>>>>>> The Glymur USB system contains 3 USB type C ports, 1 USB multiport
>>>>>> controller and a USB 2.0 only controller. This encompasses 5 SS USB QMP
>>>>>> PHYs (3 combo and 2 uni) and 6 M31 eUSB2 PHYs. All controllers are SNPS
>>>>>> DWC3 based, so describe them as flattened DWC3 QCOM nodes.
>>>>>>
>>>>>> Signed-off-by: Wesley Cheng <wesley.cheng@....qualcomm.com>
>>>>>> Co-developed-by: Abel Vesa <abel.vesa@....qualcomm.com>
>>>>>> Signed-off-by: Abel Vesa <abel.vesa@....qualcomm.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> +            snps,dis_u2_susphy_quirk;
>>>>>> +            snps,dis_enblslpm_quirk;
>>>>>> +            snps,dis_u3_susphy_quirk;
>>>>>> +            snps,usb2-lpm-disable;
>>>>>
>>>>> Other SoCs have a list that's much longer, please consult Wesley if
>>>>> this list is enough
>>>>
>>>> Checked with Wesley. He confirmed that this trimmed list is fine.
>>>> He said he dropped the rest since they are related to the power saving
>>>> features like USB2/3 LPM (l1 or u1/u2) and we don't seem need those.
>>>
>>> Is that to say that those erratas were fixed in this hardware?
>>>
>>> Low-power states of the link are no less than desired is possible..
>>>
>>
>> I think it was misunderstood.  We should keep the same quirks as our previous targets to enable USB LPM support in certain cases.
>>
>> snps,hird-threshold = /bits/ 8 <0x0>;
>> snps,usb2-gadget-lpm-disable;
>> snps,dis-u1-entry-quirk;
>> snps,dis-u2-entry-quirk;
>> snps,is-utmi-l1-suspend;
>> snps,usb3_lpm_capable;
>> snps,has-lpm-erratum;
>> tx-fifo-resize;
>> snps,dis_u2_susphy_quirk;
>> snps,dis_enblslpm_quirk;
>> snps,usb2-lpm-disable;
>>
>> There are some questionable ones that I'm on the fence though, which we should consider removing:
>> snps,usb2-lpm-disable
>> snps,usb2-gadget-lpm-disable
>>
>> USB L1 support is routinely being verified on our devices (in host and device modes), so if its power over performance, we should consider removing the properties to disable USB L1.
> 
> Does the fact that we allow L1 entry impact performance itself, or is
> there some room for improvement in the drivers?
> 

Hi Konrad,

Its not exactly something USB drivers have control of, as USB L1 LPM is a 
feature handled within the controller.  The only reason why we might see 
some performance hit is if we have to frequently enter/exit L1 states, but 
if the link never make transitions into L1, then we obviously won't take a hit.

> 
>   (esp since we're defining the HIRD threshold as well...)
> 
> Wouldn't HIRD threshold be related to *U*1(/2) though?
> I see in the list above you decalred
> 

U1/U2 are USB3 LPM states, which utilize the BESL, not HIRD.

> snps,dis-u1-entry-quirk
> snps,dis-u2-entry-quirk
> 
> which forbid them
> 

These disable them for when we are in gadget/peripheral mode, but u1/u2 
while in host mode is still enabled.  I'm not sure we are confident enough 
yet at this point to enable them (U1/U2) for device mode use cases.

> and the threshold is set to 0, so IIUC that means entry is only allowed
> for devices that don't ""really"" suspend
> 

HIRD specifies the L1 exit latency that our device will require, and 
programming that to 0 will mean we'll require the minimum HIRD latency to 
exit L1.

Thanks
Wesley Cheng