Re: [PATCH 00/14] xhci features and fixes for usb-next

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

On Fri, 9 Oct 2026 14:00:21 +0300, Mathias Nyman wrote:
> On 10/9/26 13:50, Greg KH wrote:
> > On Fri, Oct 09, 2026 at 12:58:20PM +0300, Mathias Nyman wrote:  
> >> Hi Greg
> >>
> >> xhci improvements and non-urgent fixes for usb-next.
> >>
> >> One series by Michal to improve transfer event handling, otherwise
> >> smaller scattered patches for dbc, early dbc, sideband and generic
> >> xhci cleanups.  
> > 
> > You you want me to take all the ones here that were "clean" from the
> > sashiko review, and ignore the ones that were not, or do you want me to
> > take them all now and those issues (if they are real, at least one I
> > noticed is not), will be worried about later?
> >   
> 
> Let me take a closer look, I'll send a new series today.
> 
> Some could be dropped, cleanup up, and submitted later, like [PATCH 1/14]
> 
> Others like [PATCH 10/14] is mid series, and don't want to blindly drop it
> without checking if sashiko issue is valid

Oh cool, more AI slop on linux-usb.

I don't like wasting time on that, but I understand this bot has just
been deployed and it's two weeks to merge window, so...

 [PATCH 13/14] usb: xhci: Fix bounce buffer overflow

Yes, -EPOROTO or -EOVERFLOW is roughly what one can expect when the
host and device are set up for different packet size. The patch only
tries to ensure that we don't also get memory corruption then.

We could actually try to support 1024 byte bulk high-speed endpoints
(provided that the HC doesn't reject or mishandle them), I tested this
on FX2 with appropriate FW and mentioned such possibility to Mathias,
but in absence of genuine user demand he showed no enthusiasm.

 [PATCH 10/14] usb: xhci: Don't set the skip flag on non-isoc endpoints

This is a pre-existing (non-)issue actually introduced by bfa845994282
last year. I see Mathias has just responded that this is limited to
out-of-spec host controllers which, may I add, aren't known to exist,
though other forms of bogus or mangled transfer events are known.

The code, again, only tries to prevent completely crazy things like
giving back multiple pending URBs with zero reason to believe that the
hardware will not attempt to DMA them in a moment.

Regards,
Michal