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

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

On 5/11/26 8:44 PM, Sven Peter wrote:
> Hi,
> 
> On 11.05.26 11:06, Konrad Dybcio wrote:
>> 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>

[...]

>> 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.
> 
> I'm not sure if mux is the correct framework here. On Apple Silicon we also need an out-of-band notification from the PD controller to the USB4 NHI here but the NHI isn't a mux in the typec sense. And how do you ensure that 4 happens before 6 if you use the typec mux framework or does that not matter for your platform?

Some mux provider drivers (e.g. the PS883x one) call typec_mux_get/set()
explicitly, and combining that with the right of_graph things end up
working naturally (perhaps to some degree by luck?).

With the QMPPHY specifically, it already exposes a separate struct phy
for the USB3 sub-block and another one for DP. I added a third one for
USB4, which when activated, programs it into USB4 mode and de facto
blocks the driver from acting as a typec_mux (simply via an early return
from mux_set) for the duration of the USB4PHY being in use (the router
takes care of lane assignment and orientation, when active).

Making this predictable (and controllable from the router driver) was
paramount, as the device will crash if the router is attempted to be
brought online at the wrong time, since most of its clocks are derived
from the on-PHY PLL. Similarly, the suspend flows also require tight
control of the PHY's power state.


I ended up modeling the router as a mux&switch, since like I mentioned,
it needs a number of parameters that already come via these frameworks
(cable type/speed, orientation, etc.) and the drivers needs to talk to
the MCU immediately after the PHY and retimer are set up, so that only
made sense.

> Currently I use [1] and [2] in my work-in-progress tree though I'm not quite happy with it yet.

I took a look at your branch and predictably we faced some common
obstacles.. Although I'm jealous of RTKIT..

>> 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?
> 
> I don't think so, but we need a manual out-of-band notification to both PCIe, tunneled DisplayPort and USB3 once the tunnel has been brought upside the NHI (i.e. long after the typec altmode is entered) and all this has to be represented in the device tree as well.

The DP situation in our impl is.. colorful as well.
Generally I think we only need to reset the protocol adapters, which
happen to live within the router's address space, making it contained
within the TBT driver.

> DWC3 on Apple platforms is very cursed and has to be fully offline while the Type-C switches modes and must only be brought up then once the tunnel inside the NHI has already been established.

> My current WIP code uses a tbt_oob_notify for all that that I introduced and something like this in the dt to represent the connections:
> 
> /* USB4 */
> &usb4_1_acio {
>     ports {
>         #address-cells = <1>;
>         #size-cells = <0>;
> 
>         /* 1: USB4 port */
>         port@1 {
>             reg = <1>;
>             usb4_1_acio_tbt: endpoint {
>                 remote-endpoint = <&typec1_con_tbt>;
>             };
>         };
> 
>         /* 2: unused(?) USB4 port */

Any chance port2 is used for lane bonding?

>         /* 3: PCIe, TBD */
>         /* 4: USB3, TBD */
>         /* 5: DP0, TBD */
>         /* 6: DP1, TBD */
>     };
> };
> 
> Still not completely happy with that as well.
> Does PCIe tunneling also need additional OOB notifications for you?

No, simply enabling the path works, after which we get the normal hotplug
events

Konrad