usb: hub: Don't try to recover devices lost during warm reset.

JIRA: https://issues.redhat.com/browse/RHEL-116007

commit 2521106
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date: Mon, 23 Jun 2025 16:39:47 +0300

  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 8bea2bd ("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: 8bea2bd ("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>
  Acked-by: Alan Stern <stern@rowland.harvard.edu>
  Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.intel.com
  Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Desnes Nunes <desnesn@redhat.com>

Author: Desnes Nunes

drivers/usb/core/hub.c

@@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1)
 	struct usb_device *hdev = hub->hdev;
 	u16 portstatus, portchange;
 	int i = 0;
+	int err;
 
 	connect_change = test_bit(port1, hub->change_bits);
 	clear_bit(port1, hub->event_bits);
@@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1)
 		} else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
 				|| udev->state == USB_STATE_NOTATTACHED) {
 			dev_dbg(&port_dev->dev, "do warm reset, port only\n");
-			if (hub_port_reset(hub, port1, NULL,
-					HUB_BH_RESET_TIME, true) < 0)
+			err = hub_port_reset(hub, port1, NULL,
+					     HUB_BH_RESET_TIME, true);
+			if (!udev && err == -ENOTCONN)
+				connect_change = 0;
+			else if (err < 0)
 				hub_port_disable(hub, port1, 1);
 		} else {
 			dev_dbg(&port_dev->dev, "do warm reset, full device\n");