Re: [PATCH 2/2] usb: dwc3: Notify XHCI core of tunneled status

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 5/9/26 1:31 AM, Thinh Nguyen wrote:
> 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?

For us, it seems to be hardwired (not sure if actually, but definitely
effectively) to a separate register which is used to select the right
clock mux for the USB3 protocol adapter to work (which is to be set if
USB3 tunneling is going to be used)

Moreover, the register definition for our SoCs calls all fields of
CIOCTRL read-only, whereas the DWC programming guide says they're R/W -
possibly supporting my theory above

FWIW, our Type-C infra is as such:

1. thick firmware layer running on a MCU that performs mode&PD handshakes
2. drivers/soc/qcom/pmic_glink_altmode.c receives notifications of what
   the FW had negotiated with regards to mode
3. a relatively small subset of UCSI provides PD data (and some altmode
   data)
4. drivers/phy/qualcomm/phy-qcom-qmp-combo.c reprograms the PHY based
   on typec_mux events in native cases, or to USB4/TBT mode if the router
   driver requests it [that last part is not yet upstream]
5. [optionally] retimer drivers in between (most often Parade PS883x
   series via drivers/usb/typec/mux/ps883x.c), which act as an
   additional typec_mux/switch in the chain
6. [not upstream yet] USB4 router driver consumes some typec_mux
   parameters (orientation, cable and partner capabilities) and sends a
   command to another MCU to high-speed link establishment. It also sets
   the aforementioned magic register.

At a glance, 2. seems like a reasonably fitting place to set it, however:
* it does not have any sort of a handle to the typec_connector (it
only acts like a mux that sets another mux), and
* it may be going away in the future

so I'd much prefer to keep this logic somewhere near where this iteration
of the patch does - I think it'll be useful for more implementations, as
I'd imagine it'd be fairly commonplace to hardwire CIOCTRL_CIO_EN and
another part of the pipeline that must logically be online for USB4 to
be useful

+Sven, on ASi, is CIOCTRL_CIO_EN (dwc3base + (0xcd20 + ((port) * 0x30))
written to manually?

Konrad