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

[Thinh Nguyen]

On Tue, May 12, 2026, Thinh Nguyen wrote:
> 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.
> 

Hi,

There's no cleaner way I see to do this. We can use the
"usb4-host-interface" that you proposed. We also need to consider newer
DWC_usb3x IP versions support xHCI tunneling capability bit and
PORTSC.TM. The xHCI should check for the xHCI registers before deciding
to fallback to check the xhci_plat->tunnel_mode().


Thanks,
Thinh