[PATCH 0/5] xhci fixes for usb-linus

[PATCH 0/5] xhci fixes for usb-linus

[Mathias Nyman]

Hi Greg

Some xhci fixes for usb-linus

[Patch 1/5] is a fixup patch for commit 6895dbdc19d9 ("xhci: give back
TDs and clean up ep0 after disconnect") in your usb-linus branch.

It sorts out the issue sashiko reported earlier

Thanks
Mathias

Mathias Nyman (1):
  xhci: keep port link_inactive and connected flags in sync when polled

Niklas Neronin (2):
  usb: xhci: clear stale bandwidth data after hibernation
  usb: xhci: fix 'num_active_eps' accounting on allocation failure

Rishabh Jain (1):
  usb: pci-quirks: always assert xHCI OS ownership

Xu Rao (1):
  usb: xhci: disable the correct slot on alloc_dev failure

 drivers/usb/host/pci-quirks.c | 13 ++++++++-----
 drivers/usb/host/xhci-hub.c   |  6 ++++++
 drivers/usb/host/xhci-mem.c   | 16 +++++++++++++++-
 drivers/usb/host/xhci.c       |  8 +++++++-
 4 files changed, 36 insertions(+), 7 deletions(-)

-- 
2.43.0

[PATCH 1/5] xhci: keep port link_inactive and connected flags in sync when polled

[Mathias Nyman]

Update port 'link_inactive' and 'connected' flags even if xHC isn't
generating port change events.

xHC only generates port change events on port changes after old port
change bits are cleared. Hub driver is often kept up to date
by polling the port status.

Sashiko reported a possible case where all port changes after a port
reset take place before hub driver clears the reset change bit.
This way the port can end up connected and fully running with link
in u0 without a port event clearing the 'link_inactive' or setting
the 'connected' flags.

A protocol STALL in this state would set EP_DROP_PENDING, and
prevent all future URBs for the endpoint.

Fix this by also updating the flags during get_port_status(), when
hub driver is polling the port state.

Fixes: 6895dbdc19d9 ("xhci: give back TDs and clean up ep0 after disconnect")
Link: https://lore.kernel.org/linux-usb/sashiko-outbox-190046@kernel.org/
Cc: stable <stable@kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 drivers/usb/host/xhci-hub.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 470bafe1802b..55430b673f1e 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1166,6 +1166,12 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, struct xhci_bus_state *bus_
 	if (portsc & PORT_RESET)
 		status |= USB_PORT_STAT_RESET;
 
+	/* track connect and link error status when hub is polling */
+	if (!(portsc & PORT_RESET)) {
+		port->link_inactive = (portsc & PORT_PLS_MASK) == XDEV_INACTIVE;
+		port->connected = !!(portsc & PORT_CONNECT);
+	}
+
 	/* USB2 and USB3 specific bits, including Port Link State */
 	if (hcd->speed >= HCD_USB3)
 		xhci_get_usb3_port_status(port, &status, portsc);
-- 
2.43.0

Re: [PATCH 1/5] xhci: keep port link_inactive and connected flags in sync when polled

[sashiko-bot]

> Update port 'link_inactive' and 'connected' flags even if xHC isn't
> generating port change events.
> 
> xHC only generates port change events on port changes after old port
> change bits are cleared. Hub driver is often kept up to date
> by polling the port status.
> 
> Sashiko reported a possible case where all port changes after a port
> reset take place before hub driver clears the reset change bit.
> This way the port can end up connected and fully running with link
> in u0 without a port event clearing the 'link_inactive' or setting
> the 'connected' flags.
> 
> A protocol STALL in this state would set EP_DROP_PENDING, and
> prevent all future URBs for the endpoint.
> 
> Fix this by also updating the flags during get_port_status(), when
> hub driver is polling the port state.
> 
> Fixes: 6895dbdc19d9 ("xhci: give back TDs and clean up ep0 after disconnect")
> Link: https://lore.kernel.org/linux-usb/sashiko-outbox-190046@kernel.org/
> Cc: stable <stable@kernel.org>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105175106.241182-1-mathias.nyman@linux.intel.com?part=1

Re: [PATCH 1/5] xhci: keep port link_inactive and connected flags in sync when polled

[Xu Yang]

On Thu, Nov 05, 2026 at 07:51:02PM +0200, Mathias Nyman wrote:
> Update port 'link_inactive' and 'connected' flags even if xHC isn't
> generating port change events.
> 
> xHC only generates port change events on port changes after old port
> change bits are cleared. Hub driver is often kept up to date
> by polling the port status.
> 
> Sashiko reported a possible case where all port changes after a port
> reset take place before hub driver clears the reset change bit.
> This way the port can end up connected and fully running with link
> in u0 without a port event clearing the 'link_inactive' or setting
> the 'connected' flags.
> 
> A protocol STALL in this state would set EP_DROP_PENDING, and
> prevent all future URBs for the endpoint.
> 
> Fix this by also updating the flags during get_port_status(), when
> hub driver is polling the port state.

I have encountered this issue as well. During system resume, the port link
state transitions to Inactive, causing a PLC event. However, neither the
xHCI driver nor the hub clears the PLC bit. The hub cannot process the
event either, since usb_hub_wq does not start running until it is thawed.
As a result, any subsequent link state changes do not generate new events
until the root hub port warm reset is completed. During this period, the
USB device attached to the root hub may be treated as disconnected because
all control transfers continuously fail.

This patch works for me.

Tested-by: Xu Yang <xu.yang_2@nxp.com>

Thanks,
Xu Yang

> 
> Fixes: 6895dbdc19d9 ("xhci: give back TDs and clean up ep0 after disconnect")
> Link: https://lore.kernel.org/linux-usb/sashiko-outbox-190046@kernel.org/
> Cc: stable <stable@kernel.org>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> ---
>  drivers/usb/host/xhci-hub.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 470bafe1802b..55430b673f1e 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1166,6 +1166,12 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, struct xhci_bus_state *bus_
>  	if (portsc & PORT_RESET)
>  		status |= USB_PORT_STAT_RESET;
>  
> +	/* track connect and link error status when hub is polling */
> +	if (!(portsc & PORT_RESET)) {
> +		port->link_inactive = (portsc & PORT_PLS_MASK) == XDEV_INACTIVE;
> +		port->connected = !!(portsc & PORT_CONNECT);
> +	}
> +
>  	/* USB2 and USB3 specific bits, including Port Link State */
>  	if (hcd->speed >= HCD_USB3)
>  		xhci_get_usb3_port_status(port, &status, portsc);
> -- 
> 2.43.0
> 

[PATCH 2/5] usb: xhci: disable the correct slot on alloc_dev failure

[Mathias Nyman]

From: Xu Rao <raoxu@uniontech.com>

xhci_alloc_dev() stores the Slot ID returned by the Enable Slot command
in the local slot_id variable.  udev->slot_id is updated only after
xhci_alloc_virt_device() succeeds.

If endpoint resource reservation or virtual device allocation fails
before that update, the error path passes udev->slot_id to
xhci_disable_and_free_slot().  During initial enumeration this is slot 0.
When reallocating a device whose virtual device is missing or belongs to
another usb_device, udev->slot_id may contain a stale Slot ID.
The newly enabled slot can therefore remain active, or the wrong slot can
be disabled.

Pass slot_id, which identifies the slot enabled by this invocation.
xhci_disable_and_free_slot() already handles a missing xhci->devs entry.

Fixes: 3ffbba9511b4 ("USB: xhci: Allocate and address USB devices")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Reviewed-by: Niklas Neronin <niklas.neronin@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 drivers/usb/host/xhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b50a582be1fb..94da0268b7b3 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4301,7 +4301,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
 	return 1;
 
 disable_slot:
-	xhci_disable_and_free_slot(xhci, udev->slot_id);
+	xhci_disable_and_free_slot(xhci, slot_id);
 
 	return 0;
 }
-- 
2.43.0

Re: [PATCH 2/5] usb: xhci: disable the correct slot on alloc_dev failure

[sashiko-bot]

> From: Xu Rao <raoxu@uniontech.com>
> 
> xhci_alloc_dev() stores the Slot ID returned by the Enable Slot command
> in the local slot_id variable.  udev->slot_id is updated only after
> xhci_alloc_virt_device() succeeds.
> 
> If endpoint resource reservation or virtual device allocation fails
> before that update, the error path passes udev->slot_id to
> xhci_disable_and_free_slot().  During initial enumeration this is slot 0.
> When reallocating a device whose virtual device is missing or belongs to
> another usb_device, udev->slot_id may contain a stale Slot ID.
> The newly enabled slot can therefore remain active, or the wrong slot can
> be disabled.
> 
> Pass slot_id, which identifies the slot enabled by this invocation.
> xhci_disable_and_free_slot() already handles a missing xhci->devs entry.
> 
> Fixes: 3ffbba9511b4 ("USB: xhci: Allocate and address USB devices")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
> Reviewed-by: Niklas Neronin <niklas.neronin@linux.intel.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105175106.241182-1-mathias.nyman@linux.intel.com?part=2

[PATCH 3/5] usb: pci-quirks: always assert xHCI OS ownership

[Mathias Nyman]

From: Rishabh Jain <rishabh.jain1198@gmail.com>

The xHCI ownership protocol requires the OS driver to assert the HC OS
Owned semaphore before using the host controller, then wait for HC BIOS
Owned to clear if firmware owns it.

quirk_usb_handoff_xhci() currently asserts OS Owned only when BIOS Owned
is already set. If firmware leaves BIOS Owned clear, Linux uses the xHC
while both ownership semaphores remain clear.

The timeout fallback also clears BIOS Owned using the original register
value, which can clear OS Owned at the same time.

On an AMD PROM21 xHCI controller (1022:43fc), this caused every S3
resume to terminate Controller Restore State with USBSTS 0x401. Linux
then reset the host controller, both root hubs and the USB Bluetooth
adapter.

The controller entered resume ready and halted with USBSTS 0x1.
Endpoint state, 100 ms save/restore delays, scratchpads, the DCBAA,
device contexts and command, event and transfer rings were verified not
to cause the restore error.

Across four S3 cycles, asserting only HC OS Owned changed USBLEGSUP from
0x00000801 to 0x01000801 and eliminated the restore failure. Testing
included the unmodified 7.1.8-ogc1.1.fc44.x86_64 distribution kernel
using a test module that set the HC OS Owned semaphore. The same test
was repeated after review with the same result. Clearing USBLEGCTLSTS
was independently verified to be unnecessary.

Always assert OS Owned for controllers using the standard xHCI handoff,
and leave the existing TI/Renesas forced handoff unchanged. Keep OS
Owned asserted after the standard handoff, including when forcing BIOS
Owned clear after a timeout, to prevent firmware from reclaiming the
controller during subsequent suspends.

Fixes: 66d4eadd8d06 ("USB: xhci: BIOS handoff and HW initialization.")
Cc: stable@vger.kernel.org
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tested-by: McKenna Fan <blue_sun@tuta.io>
Tested-by: Quinn Schive <quinnschive@hotmail.com>
Tested-by: Bruno Filipe <bmilreu@gmail.com>
Tested-by: Maciej Zonski <me@zonni.pl>
Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 drivers/usb/host/pci-quirks.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index f670e7aab984..1dbfd697a582 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1195,10 +1195,11 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 			 && pdev->device == 0x0014)) {
 		val = (val | XHCI_HC_OS_OWNED) & ~XHCI_HC_BIOS_OWNED;
 		writel(val, base + ext_cap_offset);
-	}
-
-	/* If the BIOS owns the HC, signal that the OS wants it, and wait */
-	if (val & XHCI_HC_BIOS_OWNED) {
+	} else {
+		/*
+		 * Perform the standard handoff and leave OS ownership set to
+		 * keep the BIOS at bay during subsequent suspends.
+		 */
 		writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
 
 		/* Wait for 1 second with 10 microsecond polling interval */
@@ -1210,7 +1211,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 			dev_warn(&pdev->dev,
 				 "xHCI BIOS handoff failed (BIOS bug ?) %08x\n",
 				 val);
-			writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
+			writel((val | XHCI_HC_OS_OWNED) &
+			       ~XHCI_HC_BIOS_OWNED,
+			       base + ext_cap_offset);
 		}
 	}
 
-- 
2.43.0

Re: [PATCH 3/5] usb: pci-quirks: always assert xHCI OS ownership

[sashiko-bot]

> From: Rishabh Jain <rishabh.jain1198@gmail.com>
> 
> The xHCI ownership protocol requires the OS driver to assert the HC OS
> Owned semaphore before using the host controller, then wait for HC BIOS
> Owned to clear if firmware owns it.
> 
> quirk_usb_handoff_xhci() currently asserts OS Owned only when BIOS Owned
> is already set. If firmware leaves BIOS Owned clear, Linux uses the xHC
> while both ownership semaphores remain clear.
> 
> The timeout fallback also clears BIOS Owned using the original register
> value, which can clear OS Owned at the same time.
> 
> On an AMD PROM21 xHCI controller (1022:43fc), this caused every S3
> resume to terminate Controller Restore State with USBSTS 0x401. Linux
> [ ... ]
> Tested-by: Quinn Schive <quinnschive@hotmail.com>
> Tested-by: Bruno Filipe <bmilreu@gmail.com>
> Tested-by: Maciej Zonski <me@zonni.pl>
> Signed-off-by: Rishabh Jain <rishabh.jain1198@gmail.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105175106.241182-1-mathias.nyman@linux.intel.com?part=3

[PATCH 4/5] usb: xhci: clear stale bandwidth data after hibernation

[Mathias Nyman]

From: Niklas Neronin <niklas.neronin@linux.intel.com>

Controllers using software managed bandwidth accounting maintain
periodic endpoint bandwidth information in struct 'xhci_interval_bw_table'.

Each root hub port owns a bandwidth table and a list of TT bandwidth
domains, where each TT has its own bandwidth table. Virtual devices
reference the bandwidth table of their current bandwidth domain through
'bw_table' or 'tt_info'.

Historically, resume from S4 reinitialized the entire xHCI driver state,
which implicitly cleared all bandwidth accounting data. After the
hibernation resume path was optimized to preserve parts of the driver
state, virtual devices and TT bandwidth information were freed and
recreated, but the root hub bandwidth tables were left intact.

As a result, stale bandwidth accounting data could remain in the root
hub bandwidth tables across hibernation resume, leading to incorrect
bandwidth calculations after devices were rediscovered.

Fix this by resetting all bandwidth accounting data in xhci_rh_bw_cleanup()
so that resume starts with a clean bandwidth state, and resetting the total
active endpoints count.

Fixes: 2a70e5dc0301 ("usb: xhci: optimize resuming from S4 (suspend-to-disk)")
Reported-by: Harald Judt <h.judt@gmx.at>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=222071
Suggested-by: Lovekesh Solanki <lovekeshsolanki00@gmail.com>
Tested-by: Harald Judt <h.judt@gmx.at>
Cc: stable <stable@kernel.org>
Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 drivers/usb/host/xhci-mem.c | 16 +++++++++++++++-
 drivers/usb/host/xhci.c     |  1 +
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index af8d4b74c4ba..75577f441cdd 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1903,24 +1903,38 @@ EXPORT_SYMBOL_GPL(xhci_remove_secondary_interrupter);
 void xhci_rh_bw_cleanup(struct xhci_hcd *xhci)
 {
 	struct xhci_root_port_bw_info *rh_bw;
+	struct xhci_interval_bw_table *bw_table;
+	struct xhci_interval_bw *interval_bw;
 	struct xhci_tt_bw_info *tt_info, *tt_next;
 	struct list_head *eps, *ep, *ep_next;
 
 	for (int i = 0; i < xhci->max_ports; i++) {
 		rh_bw = &xhci->rh_bw[i];
 
+		rh_bw->num_active_tts = 0;
 		/* Clear and free all TT bandwidth entries */
 		list_for_each_entry_safe(tt_info, tt_next, &rh_bw->tts, tt_list) {
 			list_del(&tt_info->tt_list);
 			kfree(tt_info);
 		}
 
+		bw_table = &rh_bw->bw_table;
+		bw_table->interval0_esit_payload = 0;
+		bw_table->bw_used = 0;
+		bw_table->ss_bw_in = 0;
+		bw_table->ss_bw_out = 0;
+
 		/* Clear per-interval endpoint lists */
 		for (int j = 0; j < XHCI_MAX_INTERVAL; j++) {
-			eps = &rh_bw->bw_table.interval_bw[j].endpoints;
+			interval_bw = &bw_table->interval_bw[j];
+			eps = &interval_bw->endpoints;
 
+			interval_bw->num_packets = 0;
 			list_for_each_safe(ep, ep_next, eps)
 				list_del_init(ep);
+			interval_bw->overhead[LS_OVERHEAD_TYPE] = 0;
+			interval_bw->overhead[FS_OVERHEAD_TYPE] = 0;
+			interval_bw->overhead[HS_OVERHEAD_TYPE] = 0;
 		}
 	}
 }
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 94da0268b7b3..a762dd010e8d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1185,6 +1185,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool power_lost, bool is_auto_resume)
 		for (int i = xhci->max_slots; i > 0; i--)
 			xhci_free_virt_devices_depth_first(xhci, i);
 
+		xhci->num_active_eps = 0;
 		xhci_rh_bw_cleanup(xhci);
 
 		xhci->cmd_ring_reserved_trbs = 0;
-- 
2.43.0

Re: [PATCH 4/5] usb: xhci: clear stale bandwidth data after hibernation

[sashiko-bot]

> From: Niklas Neronin <niklas.neronin@linux.intel.com>
> 
> Controllers using software managed bandwidth accounting maintain
> periodic endpoint bandwidth information in struct 'xhci_interval_bw_table'.
> 
> Each root hub port owns a bandwidth table and a list of TT bandwidth
> domains, where each TT has its own bandwidth table. Virtual devices
> reference the bandwidth table of their current bandwidth domain through
> 'bw_table' or 'tt_info'.
> 
> Historically, resume from S4 reinitialized the entire xHCI driver state,
> which implicitly cleared all bandwidth accounting data. After the
> hibernation resume path was optimized to preserve parts of the driver
> state, virtual devices and TT bandwidth information were freed and
> recreated, but the root hub bandwidth tables were left intact.
> [ ... ]
> Suggested-by: Lovekesh Solanki <lovekeshsolanki00@gmail.com>
> Tested-by: Harald Judt <h.judt@gmx.at>
> Cc: stable <stable@kernel.org>
> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105175106.241182-1-mathias.nyman@linux.intel.com?part=4

[PATCH 5/5] usb: xhci: fix 'num_active_eps' accounting on allocation failure

[Mathias Nyman]

From: Niklas Neronin <niklas.neronin@linux.intel.com>

For controllers affected by XHCI_EP_LIMIT_QUIRK, endpoint resources for
the default control endpoint are accounted before the virtual device is
allocated.

If xhci_alloc_virt_device() fails, the slot is disabled and cleanup is
handled through the Disable Slot completion path. However, because no
virtual device is installed in 'xhci->devs', the endpoint accounting
is never released and 'num_active_eps' remains incremented.

As a result, each allocation failure leaks one endpoint from the
driver's accounting.

Fix this by undoing the endpoint reservation when virtual device
allocation fails.

Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 drivers/usb/host/xhci.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a762dd010e8d..fc1b0a6b0429 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4280,6 +4280,11 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
 	 */
 	if (!xhci_alloc_virt_device(xhci, slot_id, udev, GFP_NOIO)) {
 		xhci_warn(xhci, "Could not allocate xHCI USB device data structures\n");
+		if (xhci->quirks & XHCI_EP_LIMIT_QUIRK) {
+			spin_lock_irqsave(&xhci->lock, flags);
+			xhci->num_active_eps -= 1;
+			spin_unlock_irqrestore(&xhci->lock, flags);
+		}
 		goto disable_slot;
 	}
 	vdev = xhci->devs[slot_id];
-- 
2.43.0

Re: [PATCH 5/5] usb: xhci: fix 'num_active_eps' accounting on allocation failure

[sashiko-bot]

> From: Niklas Neronin <niklas.neronin@linux.intel.com>
> 
> For controllers affected by XHCI_EP_LIMIT_QUIRK, endpoint resources for
> the default control endpoint are accounted before the virtual device is
> allocated.
> 
> If xhci_alloc_virt_device() fails, the slot is disabled and cleanup is
> handled through the Disable Slot completion path. However, because no
> virtual device is installed in 'xhci->devs', the endpoint accounting
> is never released and 'num_active_eps' remains incremented.
> 
> As a result, each allocation failure leaks one endpoint from the
> driver's accounting.
> 
> Fix this by undoing the endpoint reservation when virtual device
> allocation fails.
> 
> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105175106.241182-1-mathias.nyman@linux.intel.com?part=5