Re: [PATCH v2] usb: core: hub: Re-guess ep0 maxpacket size on reset

[Michal Pecio <michal.pecio@gmail.com>]

On Fri, 06 Nov 2026 03:34:55 +0000, sashiko-bot@kernel.org wrote:
> [Severity: Medium]
> Can calling usb_ep0_reinit(udev) here before hub_enable_device() or
> hub_set_address() trigger an invalid Evaluate Context command when
> the xHCI slot has been new

Okay, I stand corrected. Omitting the "if (!initial)" check in this
patch would cause even more warnings about failed xHCI commands.

usb_ep0_reinit() after alloc_dev() or certain reset_device() cases,
but before enable_device() or address_device(), causes xhci-hcd to
attempt some pointless nonsense, a known issue never fixed because
things still work despite the warnings.

You can work around it by adding usb_ep0_reinit() calls before the
two get_bMaxPacketSize0() calls which need them; by that time enough
setup has been done that xhci-hcd works right.

I will also look into fixing the xHCI bug because it's already being
triggered by "old scheme" enumeration on full-speed devices and it's
just lame. If the patch won't be too scary maybe we could get it to
stable and then this code would work unchanged.

> Furthermore, if a previous attempt in xhci_setup_device() failed with
> COMP_USB_TRANSACTION_ERROR, it reallocates the slot via xhci_alloc_dev() and
> calls xhci_setup_addressable_virt_dev(xhci, udev), which populates
> vdev->in_ctx (including setting slot_ctx->dev_info and initializing in_ctx
> ep0) while vdev->out_ctx remains zeroed. If hub_port_init() retries and calls
> usb_ep0_reinit(udev) before the next xhci_setup_device(),
> xhci_check_ep0_maxpacket() overwrites vdev->in_ctx ep0 from the zeroed
> vdev->out_ctx while leaving slot_ctx->dev_info non-zero:
> 
> drivers/usb/host/xhci.c:xhci_setup_device() {
> 	...
> 	if (!slot_ctx->dev_info)
> 		xhci_setup_addressable_virt_dev(xhci, udev);
> 	/* Otherwise, update the control endpoint ring enqueue pointer. */
> 	else
> 		xhci_copy_ep0_dequeue_into_input_ctx(xhci, udev);
> 	...
> }
> 
> Wouldn't xhci_setup_device() then skip xhci_setup_addressable_virt_dev() and
> submit Address Device with a zeroed ep0 context (EP_TYPE == 0)?

And this here looks like another related bug which may cause real
functional failure if it can be triggered.

Regards,
Michal