All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.