Re: [PATCH v2 2/4] usb: xhci: Honor PORTSC.TM if valid
Mathias Nyman <[email protected]> Fri, 31 Jul 2026 13:34:37 +0300
| Newsgroups | org.kernel.vger.linux-usb,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 7/28/26 11:44, Konrad Dybcio wrote: > On 7/23/26 12:57 AM, Thinh Nguyen wrote: >> On Wed, Jul 15, 2026, Konrad Dybcio wrote: >>> From: Konrad Dybcio <[email protected]> >>> >>> Currently, the only way for the USB core to determine whether the link >>> is native or tunneled is via an Intel vendor-specific Extended >>> Capability. > > [...] > >>> - /* Don't try and probe this capability for non-Intel hosts */ >>> + /* Prefer the XHCI v1.2 ext_cap if advertised */ >>> + offset = xhci_find_next_ext_cap(base, 0, XHCI_EXT_CAPS_USB3_TUNNELING); >>> + if (offset) { >>> + if (!(readl(base + offset) & XHCI_USB3_TUNNELING_SUPPORTED)) >>> + return USB_LINK_NATIVE; >> >> Second, don't return early here. Check if XHCI_EXT_CAPS_USB3_TUNNELING >> present and supported: > > So if the extcap is supported and exposed, but it says "this port > is not tunneling-capable", can we not trust that data? The extcap 18 bit only states if tunnel mode bit reporting in PORTSC is supported, not if port is tunnel capable. Supporting tunneling and exposing extended capability ID 18, but not reporting tunneling in PORTSC register would be odd, but due to the phrasing it could be possible. Thanks Mathias