Re: [PATCH] usb: hub: Don't try to recover devices lost during warm reset.

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jun 23, 2025 at 04:39:47PM +0300, Mathias Nyman wrote:
> Hub driver warm-resets ports in SS.Inactive or Compliance mode to
> recover a possible connected device. The port reset code correctly
> detects if a connection is lost during reset, but hub driver
> port_event() fails to take this into account in some cases.
> port_event() ends up using stale values and assumes there is a
> connected device, and will try all means to recover it, including
> power-cycling the port.
> 
> Details:
> This case was triggered when xHC host was suspended with DbC (Debug
> Capability) enabled and connected. DbC turns one xHC port into a simple
> usb debug device, allowing debugging a system with an A-to-A USB debug
> cable.
> 
> xhci DbC code disables DbC when xHC is system suspended to D3, and
> enables it back during resume.
> We essentially end up with two hosts connected to each other during
> suspend, and, for a short while during resume, until DbC is enabled back.
> The suspended xHC host notices some activity on the roothub port, but
> can't train the link due to being suspended, so xHC hardware sets a CAS
> (Cold Attach Status) flag for this port to inform xhci host driver that
> the port needs to be warm reset once xHC resumes.
> 
> CAS is xHCI specific, and not part of USB specification, so xhci driver
> tells usb core that the port has a connection and link is in compliance
> mode. Recovery from complinace mode is similar to CAS recovery.
> 
> xhci CAS driver support that fakes a compliance mode connection was added
> in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
> 
> Once xHCI resumes and DbC is enabled back, all activity on the xHC
> roothub host side port disappears. The hub driver will anyway think
> port has a connection and link is in compliance mode, and hub driver
> will try to recover it.
> 
> The port power-cycle during recovery seems to cause issues to the active
> DbC connection.
> 
> Fix this by clearing connect_change flag if hub_port_reset() returns
> -ENOTCONN, thus avoiding the whole unnecessary port recovery and
> initialization attempt.
> 
> Cc: stable@vger.kernel.org
> Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
> Tested-by: Łukasz Bartosik <ukaszb@chromium.org>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> ---
>  drivers/usb/core/hub.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

Alan, any objection to this?

thanks,

greg k-h