On Fri, May 08, 2026, Konrad Dybcio wrote:
> 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..

Ok.

> 
> 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)
> 

For the DWC3_CIOCTRL_CIO_EN to be set, it needs to be done by the type-c
driver after detecting alternate mode right? How is it being done now?
Can the udev->tunnel_mode be updated directly by your type-c driver
when it sets DWC3_CIOCTRL_CIO_EN?

BR,
Thinh