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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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@oss.qualcomm.com>
>>>>
>>>> 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.

Konrad