linux-kernel - Re: [PATCH] usb: dwc3: Fix latency of DSTS while receiving wakeup event

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: <20240806235142.cem5f635wmds4bt4@synopsys.com>
Date: Tue, 6 Aug 2024 23:51:47 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Prashanth K <quic_prashk@...cinc.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] usb: dwc3: Fix latency of DSTS while receiving wakeup
 event

Hi,

On Tue, Jul 30, 2024, Prashanth K wrote:
> When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't
> update link state immediately after receiving the wakeup interrupt. Since
> wakeup event handler calls the resume callbacks, there is a chance that
> function drivers can perform an ep queue. Which in turn tries to perform
> remote wakeup from send_gadget_ep_cmd(), this happens because DSTS[[21:18]
> wasn't updated to U0 yet. It is observed that the latency of DSTS can be
> in order of milli-seconds. Hence update the dwc->link_state from evtinfo,
> and use this variable to prevent calling remote wakup unnecessarily.
> 
> Fixes: ecba9bc9946b ("usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer")

This commit ID is corrupted. Please check.

While operating in usb2 speed, if the device is in low power link state
(L1/L2), CMDACT may not complete and time out. The programming guide
suggested to initiate remote wakeup to bring the device to ON state,
allowing the command to go through. However, clearing the
GUSB2PHYCFG.suspendusb2 turns on the signal required to complete a
command within 50us. This happens within the timeout required for an
endpoint command. As a result, there's no need to perform remote wakeup.

For usb3 speed, if it's in U3, the gadget is in suspend anyway. There
will be no ep_queue to trigger the Start Transfer command.

You can just remove the whole Start Transfer check for remote wakeup
completely.

Thanks,
Thinh