From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Jack Pham <jack.pham@oss.qualcomm.com>
Cc: 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 2/2] usb: dwc3: Notify XHCI core of tunneled status
Date: Fri, 8 May 2026 14:04:23 +0200 [thread overview]
Message-ID: <670f9a9f-54b9-4109-986e-5071caf1dcaf@oss.qualcomm.com> (raw)
In-Reply-To: <af0SM3C5qHc73DM8@vbox>
On 5/8/26 12:46 AM, Thinh Nguyen wrote:
> On Thu, May 07, 2026, Jack Pham wrote:
>> On Thu, May 07, 2026 at 12:34:50PM +0200, Konrad Dybcio wrote:
>>> On 5/7/26 1:40 AM, Thinh Nguyen wrote:
>>>> On Tue, May 05, 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. This depends on
>>>>> first knowing whether a connection is tunneled or native.
>>>>>
>>>>> Add the logic to handle that for DWC3 controllers.
>>>>>
>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>> ---
>>>>> drivers/usb/dwc3/core.c | 12 ++++++++++++
>>>>> drivers/usb/dwc3/core.h | 18 ++++++++++++++++++
>>>>> drivers/usb/dwc3/host.c | 12 ++++++++++++
>>>>> 3 files changed, 42 insertions(+)
>>>>>
>>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>>> index 65213896de99..7cec4911e278 100644
>>>>> --- a/drivers/usb/dwc3/core.c
>>>>> +++ b/drivers/usb/dwc3/core.c
>>>>> @@ -162,6 +162,18 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode, bool ignore_susphy)
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(dwc3_set_prtcap);
>>>>>
>>>>> +enum usb_link_tunnel_mode dwc3_link_tunnel_mode(struct dwc3 *dwc, u8 port)
>>>>> +{
>>>>> + /* Prior versions had no CIO support */
>>>>> + if (!DWC3_VER_IS_WITHIN(DWC31, 191A, ANY))
>>>>> + return USB_LINK_NATIVE;
>>>>> +
>>>>> + if (dwc3_readl(dwc, DWC3_CIOCTRL(port)) & DWC3_CIOCTRL_CIO_EN)
>>>>
>>>> The CIO register block only exists if DWC1_USB31_EN_CIO is set (and
>>>> DWC_USB31_EN_USB2_ONLY is not set). In most cases, this register block
>>>> will be reserved, register read of reserved block should be 0. But we
>>>> can't guarantee that it will always be the case.
>>>
>>> That's inconvenient because..
>>>
>>> [...]
>>>
>>>> We shouldn't need to be doing this. This should be checked from the
>>>> xHCI driver. Check xHCI spec for PORTSC.TM and USB3 tunneling support
>>>> capability (section 7.11).
>>>
>>> ..I'm seeing only caps 0/1/2 (and 10 on some but not all) advertised
>>> (I ran a for-loop checking offsets 0..=255)
>>
>> Right. That section in xHCI spec was only added in the 1.2b revision.
>> However the DWC31 IP versions that current Qualcomm USB4-capable SoCs
>> are using are 2.00a (and a customized version of 1.91a) which are only
>> compliant to xHCI 1.1 so this capability is not there, even though the
>> CIO register block exists. So short of having the proper XHCI bit, this
>> is the next best, non-SoC specific alternative we've found that can
>> allow XHCI driver to identify when it is operating in tunnel mode.
>>
>
> I see. If you're using 2.00a, then we can't use the xHCI's capability
> register and PORTSC.TM.
>
> Can we match the compatible string to check for CIO capability and have
> this passed from your glue driver before accessing the CIO registers?
Hm, we currently use a shared compatible string for the USB3+4 (1.91a-xxx)
and USB2 (3.30a) hosts on the USB4-capable platforms..
Another idea would be to bail out if
!device_property_present(dev, "usb4-host-interface")
which would place the burden of making sure the DT makes sense on the
programmer (which is OK in my view)
Konrad
next prev parent reply other threads:[~2026-05-08 12:04 UTC|newest]
Thread overview: 16+ 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
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 [this message]
2026-05-08 23:31 ` Thinh Nguyen
2026-05-11 9:06 ` Konrad Dybcio
2026-05-11 18:44 ` Sven Peter
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=670f9a9f-54b9-4109-986e-5071caf1dcaf@oss.qualcomm.com \
--to=konrad.dybcio@oss.qualcomm.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack.pham@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