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

On Tue, Jul 28, 2026, Konrad Dybcio wrote:
> On 7/23/26 12:37 AM, Thinh Nguyen wrote:
> > On Wed, Jul 15, 2026, Konrad Dybcio wrote:
> >> From: Konrad Dybcio <[email protected]>
> >>
> >> 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 <[email protected]>
> >> ---
> 
> [...]
> 
> >> 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)
> 

I was thinking of a hypothetical scenario where we may need to override
the standard check. Now that I think about it again, it's not a good
idea to do that without any use case yet. The way you have it is fine.

Thanks,
Thinh