linux-kernel - Re: [PATCH v11 13/13] arm64: dts: qcom: sa8540-ride: Enable first port of tertiary usb controller

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: <e7e4fc1e-661a-fd62-e8b1-1e173cbfcd3e@quicinc.com>
Date:   Thu, 14 Sep 2023 21:15:21 +0530
From:   Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Andy Gross <agross@...nel.org>,
        "Bjorn Andersson" <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        Felipe Balbi <balbi@...nel.org>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        Johan Hovold <johan@...nel.org>,
        Mathias Nyman <mathias.nyman@...el.com>
CC:     <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <quic_pkondeti@...cinc.com>, <quic_ppratap@...cinc.com>,
        <quic_jackp@...cinc.com>, <ahalaney@...hat.com>,
        <quic_shazhuss@...cinc.com>
Subject: Re: [PATCH v11 13/13] arm64: dts: qcom: sa8540-ride: Enable first
 port of tertiary usb controller



On 9/13/2023 5:40 PM, Konrad Dybcio wrote:
> On 7.09.2023 05:36, Krishna Kurapati PSSNV wrote:
>>
>>
>>> Is there any benefit to removing the other ports?
>>>
>>> i.e. are ports 1-3 not parked properly by the dwc3 driver if
>>> they're never connected to anything?
>>>
>> Hi Konrad,
>>
>>   Whether or not the phy is connected to a port, the controller would modify the GUSB2PHYCFG/GUSB3PIPECTL registers. But if we don't specify only one phy and let phys from base DTSI take effect (4 HS / 2 SS), we would end up initializing and powering on phy's which are never connected to a port. To avoid that we need to specify only one phy for this platform.
> And does that have any major effect on power use?
> 
> Do these PHYs not have some dormant/low power mode?
> 
Hi Konrad,

  I believe there will be some minimal power use. IMO its best to keep 
only one phy enabled for this variant instead of giving all and 
initializing/powering-on all 4 of them.

Regards,
Krishna,