From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Michal Pecio <michal.pecio@gmail.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: xhci: Fix ep0 maxpacket update on enabled slots
Date: Mon, 9 Nov 2026 16:57:56 +0200 [thread overview]
Message-ID: <70031d2d-e9c4-4efd-a4f8-9e60e9b66a52@linux.intel.com> (raw)
In-Reply-To: <20261109112846.04bfeb0f.michal.pecio@gmail.com>
On 11/9/26 12:28, Michal Pecio wrote:
> A slot in Enabled state has uninitialized output contexts;
> it doesn't need and cannot accept Evaluate Context command.
> Attempting the command only results in a (harmless) warning,
> observed when core uses "old scheme" on a full-speed device:
>
> WARN: invalid context state for evaluate context command.
>
> This problem doesn't seem to have existed before ep0 update
> was moved from urb_enqueue() to endpoint_reset(). USB core
> doesn't use URBs before enable_device() or address_device(),
> but it may call endpoint_reset() on ep0.
>
> A more serious bug has been identified by Sashiko review bot.
> Transaction Error of Address Device may cause the slot to be
> reallocated and left in Enabled state, but the input context
> is (needlessly) regenerated before actually being needed by
> the next Address Device. xhci_check_ep0_maxpacket() corrupts
> this context by copying uninitialized ep0 output context.
>
> This matters when core resets a device and doesn't reallocate
> udev after address_device() errors. Some HCs reject the next
> Address Device with Parameter Error, some break. ASMedia HCs
> write a Setup Stage TRB to the event ring and stop working:
>
> ERROR unknown event type 2
> INFO: task usbreset:4071 blocked for more than 122 seconds.
>
> This exact case is a relatively recent regression, but even
> if xhci_setup_device() didn't regenerate the input context
> on Transaction Error, next iteration could regenerate it and
> keep it there when command timeout leaves the slot Enabled.
>
> We can kill both bugs with one stone by checking slot state.
> If it's Enabled, do nothing and let next xhci_setup_device()
> configure ep0 later. It will actually ignore the packet size
> requested by core, but its defaults match core expectations
> at the time of address_device() and enable_device() calls.
>
> Fixes: e34900f46cd6 ("xhci: Reconfigure endpoint 0 max packet size only during endpoint reset")
> Fixes: af8e119f52e9 ("xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration")
> Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Added to queue
Thanks
Mathias
prev parent reply other threads:[~2026-11-09 14:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 10:28 [PATCH] usb: xhci: Fix ep0 maxpacket update on enabled slots Michal Pecio
2026-11-09 10:34 ` sashiko-bot
2026-11-09 14:57 ` Mathias Nyman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=70031d2d-e9c4-4efd-a4f8-9e60e9b66a52@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.