linux-kernel - Re: [PATCH 2/3] USB: dwc3: qcom: fix wakeup after probe deferral

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: <ac838113-501a-4f2b-b858-c59f586a9f35@quicinc.com>
Date:   Tue, 21 Nov 2023 19:38:18 +0530
From:   Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To:     Johan Hovold <johan@...nel.org>
CC:     Andrew Halaney <ahalaney@...hat.com>,
        Johan Hovold <johan+linaro@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH 2/3] USB: dwc3: qcom: fix wakeup after probe deferral

>>    Just one query. Even if it wakes up after closing the lid and removing
>> the mouse, wouldn't pm suspend be triggered again later by the system
>> once it sees that usb is also good to be suspended again ? I presume a
>> laptop form factor would be having this facility of re-trigerring
>> suspend. Let me know if this is not the case.
> 
> No, we generally don't use opportunistic suspend (e.g. unlike android)
> so the laptop will not suspend again.
> 
> So this is an actual bug affecting, for example, the Lenovo ThinkPad
> X13s.
> 
Thanks for the clarification. I was thinking in android perspective 
only. But if we don't wake up the system upon disconnect, wouldn't the 
controller still be under the assumption that device is connected when 
it is actually not and only realise this when we resume later ?

>> Also, the warning you are mentioning in [1] comes because this is a
>> laptop form factor and we have some firmware running (I don't know much
>> about ACPI and stuff) ?
> 
> No, the "firmware" in this case is just the devicetree which has the
> DP/DM interrupts defined as edge-triggered while the driver requests
> them as level triggered.
> 
> (It would look similar with ACPI firmware which also has these declared
> as edge triggered.)
> 
Got it. Thanks for the clarification.

Regards,
Krishna,