On Sat, Jul 12, 2025 at 12:11:38AM +0000, Thinh Nguyen wrote:

On Thu, Jul 10, 2025, John Keeping wrote:

quoted

When the phy is acting as a Type C mux, it may need to reset when the
cable direction changes.  But this should not happen while DWC3 is
trying to use the USB connection.

In this case, there must be a connection manager to notify the phy of
the orientation change and tcpm_mux_set() ensures this happens before
DWC3's role switch is informed of a change.

It should not be possible to go directly from device->device or
host->host with a change in orientation without transitioning through
the "none" role as the cable is unplugged.  So ensuring that DWC3 always

The controller is either host or device mode. It's odd to use "none" to
indicate connection.

There is no connection in this state.  When the type C controller
indicates that the role is "none" then there cannot be a USB connection.

quoted

informs the phy of the new mode whenever a plug is detected should be
sufficient for the phy to safely reset itself at a time that is safe for
DWC3.

Couldn't the phy do this as it detects connection/disconnection.

I don't think the phy can detect a connection.  If it is configured for
the wrong orientation then it will not monitor the correct data lines.
The phy hardware does not signal any interrupts to the CPU for the
driver to react to.

It seems what you need is a full controller initialization upon new
connection on orientation change, and you're using role_switch selecting
"none" to do so.

I'm not sure whether a complete initialization is necessary, but what I
want to avoid is the phy resetting while the controller is part-way
through device enumeration or setting up a gadget configuration.

It may be that simply avoiding resetting the phy if the orientation is
unchanged is enough to avoid some of this problem, but I suspect there
are still problems if the clocks from the phy to the controller are
stopped unexpectedly.  However, I have run some tests of this change and
it looks promising.

I'm not sure if role-switch has the right interface to do so. Perhaps we
can introduce one? I don't think we should change the behavior of the
current flow and apply that to all other platforms.

I don't think it's unreasonable for the controller to be idle when there
is an external type C controller notifying the connection state.

The hardware setup looks like this, with the Linux type C code notifying
the phy driver of the orientation change and the DWC3 driver of the role
change:

                      +------+          
                      | DWC3 |<----+    
                      +--^---+     |    
                         |         |    
                      +--v--+      |    
                +---->| PHY |      |Role
                |     +--^--+      |    
    Orientation |        |         |    
                |   +----v----+    |    
                +---+ FUSB302 +----+    
                    +---------+

The advantage of using the role hook is that we are guaranteed that it
is called after the phy has been notified of the orientation change.

Do you have an idea of a new interface?  Or do you think it is safe to
reset the phy underneath the controller when that will halt the clocks
from the phy to the controller for some period of time?


Regards,
John