From: "Michał Pecio" <michal.pecio@gmail.com>
To: "Rangoju, Raju" <raju.rangoju@amd.com>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, mathias.nyman@intel.com,
mathias.nyman@linux.intel.com, stable@vger.kernel.org
Subject: Re: [PATCH v4] usb: xhci: quirk for data loss in ISOC transfers
Date: Thu, 27 Mar 2025 10:34:43 +0100 [thread overview]
Message-ID: <20250327103443.682f4cd1@foxbook> (raw)
In-Reply-To: <bb78e164-f24f-49d2-b560-24d097cb2827@amd.com>
On Thu, 27 Mar 2025 12:08:53 +0530, Rangoju, Raju wrote:
> > What if there is an ISOC IN endpoint with 64ms ESIT? I haven't yet
> > seen such a slow isoc endpoint, but I think they are allowed by the
> > spec. Your changelog suggests any periodic IN endpoint can trigger
> > this bug.
>
> If such an endpoint is implemented, it could theoretically contribute
> to scheduling conflicts similar to those caused by INT endpoints in
> this context. However, our observations and testing on affected
> platforms primarily involved periodic IN endpoints with service
> intervals greater than 32ms interfering with ISOC OUT endpoints.
In such case it would make sense to drop the check for
usb_endpoint_xfer_int(&ep->desc)
and rely on existing (xfer_int || xfer_isoc) in the outer 'if'.
> I'm not completely sure about this corner case if HS OUT endpoints
> can inadvertently get affected when co-existing with long-interval
> LS/FS IN endpoints. Our IP vendor confirmed that LS/FS devices are
> not affected.
There is also a third case of a FS device behind an external HS hub.
The device will look like FS to this code here, but the xHC will need
to schedule HS transactions to service it.
Regards,
Michal
next prev parent reply other threads:[~2025-03-27 9:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 12:06 [PATCH v4] usb: xhci: quirk for data loss in ISOC transfers Raju Rangoju
2025-01-29 12:38 ` Mathias Nyman
2025-03-26 4:01 ` Rangoju, Raju
2025-03-26 6:47 ` Michał Pecio
2025-03-27 6:38 ` Rangoju, Raju
2025-03-27 9:34 ` Michał Pecio [this message]
2025-03-27 11:02 ` Rangoju, Raju
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=20250327103443.682f4cd1@foxbook \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=raju.rangoju@amd.com \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox