From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mathias Nyman <mathias.nyman@intel.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"usb4-upstream@oss.qualcomm.com" <usb4-upstream@oss.qualcomm.com>,
Raghavendra Thoorpu <rthoorpu@qti.qualcomm.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH v2 3/4] usb: xhci: Allow custom op for usb_link_tunnel_mode reporting
Date: Tue, 4 Aug 2026 21:25:15 +0000 [thread overview]
Message-ID: <anJX3m5KgC3e5zUB@vbox> (raw)
In-Reply-To: <f26077aa-f3b4-43b8-b173-f40f0aafbb9c@oss.qualcomm.com>
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 <konrad.dybcio@oss.qualcomm.com>
> >>
> >> 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@oss.qualcomm.com>
> >> ---
>
> [...]
>
> >> 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
next prev parent reply other threads:[~2026-08-04 22:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 12:29 [PATCH v2 0/4] DWC3 link tunneling state reporting Konrad Dybcio
2026-07-15 12:29 ` [PATCH v2 1/4] usb: xhci: debugfs: Expose the USB3 tunneling ext_cap register value Konrad Dybcio
2026-07-15 12:29 ` [PATCH v2 2/4] usb: xhci: Honor PORTSC.TM if valid Konrad Dybcio
2026-07-22 22:57 ` Thinh Nguyen
2026-07-28 8:44 ` Konrad Dybcio
2026-07-31 10:34 ` Mathias Nyman
2026-07-31 10:53 ` Konrad Dybcio
2026-08-04 22:37 ` Thinh Nguyen
2026-08-04 21:29 ` Thinh Nguyen
2026-07-31 10:51 ` Mathias Nyman
2026-07-31 11:01 ` Konrad Dybcio
2026-07-15 12:29 ` [PATCH v2 3/4] usb: xhci: Allow custom op for usb_link_tunnel_mode reporting Konrad Dybcio
2026-07-22 22:37 ` Thinh Nguyen
2026-07-28 8:41 ` Konrad Dybcio
2026-08-04 21:25 ` Thinh Nguyen [this message]
2026-07-15 12:29 ` [PATCH v2 4/4] usb: dwc3: Notify XHCI core of tunneled status Konrad Dybcio
2026-07-22 23:01 ` Thinh Nguyen
2026-07-28 8:48 ` Konrad Dybcio
2026-07-15 12:58 ` [PATCH v2 0/4] DWC3 link tunneling state reporting Konrad Dybcio
2026-07-22 23:07 ` Thinh Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anJX3m5KgC3e5zUB@vbox \
--to=thinh.nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rthoorpu@qti.qualcomm.com \
--cc=usb4-upstream@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox