Re: [PATCH v2 2/4] usb: xhci: Honor PORTSC.TM if valid

[Thinh Nguyen]

On Fri, Jul 31, 2026, Konrad Dybcio wrote:
> On 7/31/26 12:34 PM, Mathias Nyman wrote:
> > 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 <konrad.dybcio@xxxxxxxxxxxxxxxx>
> >>>>
> >>>> 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.
> 
> You're right.
> 

Good catch.

BR,
Thinh