All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Konrad Dybcio <konradybcio@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	usb4-upstream@oss.qualcomm.com,
	Raghavendra Thoorpu <rthoorpu@qti.qualcomm.com>
Subject: Re: [PATCH 1/2] usb: host: xhci: Allow non-Intel usb_link_tunnel_mode reporting
Date: Thu, 7 May 2026 14:53:22 +0200	[thread overview]
Message-ID: <cf71a13b-dd6d-4234-89f0-42eb6ea117fc@oss.qualcomm.com> (raw)
In-Reply-To: <803cc760-93f3-429e-bae3-669f86c07585@linux.intel.com>

On 5/7/26 2:48 PM, Mathias Nyman wrote:
> On 5/7/26 13:40, Konrad Dybcio wrote:
>> On 5/5/26 2:14 PM, Mika Westerberg wrote:
>>> Hi,
>>>
>>> On Tue, May 05, 2026 at 10:55:04AM +0200, 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>
>>>> ---
>>>>   drivers/usb/host/xhci-hub.c  | 4 ++--
>>>>   drivers/usb/host/xhci-plat.c | 2 ++
>>>>   drivers/usb/host/xhci-plat.h | 1 +
>>>>   drivers/usb/host/xhci.c      | 6 +++++-
>>>>   drivers/usb/host/xhci.h      | 5 ++++-
>>>>   5 files changed, 14 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
>>>> index bacd0ddd0d09..09e5da912066 100644
>>>> --- a/drivers/usb/host/xhci-hub.c
>>>> +++ b/drivers/usb/host/xhci-hub.c
>>>> @@ -750,7 +750,7 @@ static int xhci_exit_test_mode(struct xhci_hcd *xhci)
>>>>   }
>>>>     /**
>>>> - * xhci_port_is_tunneled() - Check if USB3 connection is tunneled over USB4
>>>> + * xhci_port_tunnel_mode() - Check if USB3 connection is tunneled over USB4
>>>>    * @xhci: xhci host controller
>>>>    * @port: USB3 port to be checked.
>>>>    *
>>>> @@ -764,7 +764,7 @@ static int xhci_exit_test_mode(struct xhci_hcd *xhci)
>>>>    * detecting USB3 over USB4 tunnels. USB_LINK_NATIVE or USB_LINK_TUNNELED
>>>>    * otherwise.
>>>>    */
>>>> -enum usb_link_tunnel_mode xhci_port_is_tunneled(struct xhci_hcd *xhci,
>>>> +enum usb_link_tunnel_mode xhci_port_tunnel_mode(struct xhci_hcd *xhci,
>>>>                           struct xhci_port *port)
>>>
>>> I'm wondering if this could be:
>>>
>>> bool xhci_port_is_tunneled()
>>>
>>> becase if I understand correctly that's the only information we need e.g is
>>> it going over tunnel or not.
>>
>> It was originally introduced as a tristate enum in:
>>
>> f46a6e165197 ("usb: Add tunnel_mode parameter to usb device structure")
>>
>> but the usefulness of USB_LINK_UNKNOWN is limited to a dev_dbg() print..
>> I don't really have strong opinions either way
>>
> 
> Tunnel detection can be tried other ways if state is USB_LINK_UNKNOWN.
> 
> For example usb-acpi.c will try to create a tunnel if all the ACPI entries exists
> that indicate a tunnel, but the current xHC doesn't support tunnel detection.

Fair, I didn't consider that!

Konrad

  reply	other threads:[~2026-05-07 12:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05  8:55 [PATCH 0/2] DWC3 link tunneling state reporting Konrad Dybcio
2026-05-05  8:55 ` [PATCH 1/2] usb: host: xhci: Allow non-Intel usb_link_tunnel_mode reporting Konrad Dybcio
2026-05-05 12:14   ` Mika Westerberg
2026-05-07 10:40     ` Konrad Dybcio
2026-05-07 12:48       ` Mathias Nyman
2026-05-07 12:53         ` Konrad Dybcio [this message]
2026-05-07 13:11           ` Mika Westerberg
2026-05-05  8:55 ` [PATCH 2/2] usb: dwc3: Notify XHCI core of tunneled status Konrad Dybcio
2026-05-06 23:40   ` Thinh Nguyen
2026-05-07 10:34     ` Konrad Dybcio
2026-05-07 17:46       ` Jack Pham
2026-05-07 22:46         ` Thinh Nguyen
2026-05-08 12:04           ` Konrad Dybcio
2026-05-08 23:31             ` Thinh Nguyen
2026-05-11  9:06               ` Konrad Dybcio
2026-05-11 18:44                 ` Sven Peter
2026-05-12 11:56                   ` Konrad Dybcio
2026-05-12  1:27                 ` Thinh Nguyen
2026-05-14  1:21                   ` 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=cf71a13b-dd6d-4234-89f0-42eb6ea117fc@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=konradybcio@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.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.