Linux USB
 help / color / mirror / Atom feed
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

  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