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

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Mon, May 11, 2026, Konrad Dybcio wrote:
> On 5/9/26 1:31 AM, Thinh Nguyen wrote:
> > 
> > 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
> 

Thanks for the details. Let me get back after discussing with our team
internally.

BR,
Thinh