Re: [PATCH v2 3/4] usb: xhci: Allow custom op for usb_link_tunnel_mode reporting

[Konrad Dybcio]

On 7/23/26 12:37 AM, Thinh Nguyen wrote:
> On Wed, Jul 15, 2026, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>>
>> The Thunderbolt framework relies on the USB core to create device links
>> for tunneled ports, so that the USB3 controller is only kept
>> runtime-resumed for the duration of the tunneling.
>>
>> Currently, retrieving that information is only possibe on Intel XHCI
>> hosts, through a vendor-specific capability. Extend xhci-plat to allow
>> plumbing a custom one.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>> ---

[...]

>> diff --git a/drivers/usb/host/xhci-plat.h b/drivers/usb/host/xhci-plat.h
>> index 00751d851831..c5042766a486 100644
>> --- a/drivers/usb/host/xhci-plat.h
>> +++ b/drivers/usb/host/xhci-plat.h
>> @@ -22,6 +22,7 @@ struct xhci_plat_priv {
>>  	int (*suspend_quirk)(struct usb_hcd *);
>>  	int (*resume_quirk)(struct usb_hcd *);
>>  	int (*post_resume_quirk)(struct usb_hcd *);
>> +	enum usb_link_tunnel_mode (*tunnel_mode)(struct usb_hcd *hcd, int portnum);
> 
> We should add a boolean tunnel_mode_override. When set, ->tunnel_mode()
> is called before the standard xhci v1.2 ext_cap check. If the
> ->tunnel_mode() returns USB_LINK_UNKNOWN, go to the standard path. This
> allows the quirk to selectively bypass or override it.

That's contrary to my understanding of what we were supposed to achieve
with the introduction of the standard check (i.e. one would expect that
if the standard capability is exposed, we should check it, and only
fall back to the platform-specific one if we must)

Konrad