Hello Vinod,

On Mon, Oct 05, 2026 at 10:30:24AM +0200, Vinod Koul wrote:
> On 04-10-26, 14:44, Sebastian Reichel wrote:
> > On Sat, Oct 03, 2026 at 11:04:13AM +0200, Vinod Koul wrote:
> > > On 24-09-26, 19:25, Sebastian Reichel wrote:
> > > > Some PHY devices with multiple ports (e.g. USB3 and DP) require a reset
> > > > if the configuration changes or cable orientation changes. This is a
> > > > problem, as the consumer device will run into undefined behavior.
> > > > 
> > > > With the new PHY notifier API introduced in this patch, the consumer
> > > > driver can hook into reset events coming from a PHY device to handle the
> > > > PHY going down gracefully.
> > > > 
> > > > Note that this uses -ENOSYS instead of the more sensible -ENOTSUP for
> > > > the stub functions when GENERIC_PHY is disabled to stay consistent with
> > > > the existing ones.
> > > 
> > > I dont think this series has the usage of this.
> > > 
> > > I think I am still not convinced why a phy should notify as I dont feel
> > > we have any mechanism to notifying. Checking status and letting people
> > > know if not really a notification mechanism... Maybe add a status call
> > > instead?
> > 
> > This series contains the infrastructure and the consumer of the PHY
> > reset notification (dwc3 rockchip glue driver). The producer/sender
> > of the PHY reset notification is the first patch in the USBDP part 3
> > series. I grouped the patches like this, so that this series has PHY
> > patches followed by USB patches instead of PHY - USB - PHY. Patches
> > must be applied in the exact order (i.e. first the patches added the
> > PHY reset notifier infrastructure, then the DWC3 notification
> > consumer and then the USBDP notification producer).
> > 
> > The broader picture solved by this is (pre-existing race condition
> > issue in USBDP):
> 
> Thanks, this is helpful to understand the context. Few questions on
> below to help me understand more...
> 
> > 
> > 1. USBDP PHY provides critical resources to DWC3 USB controller
> 
> what resources are these?

The documentation I have is not perfect, but my understanding is,
that it is effectively a clock.

> > 2. USBDP PHY needs to reset to reconfigure (e.g. enable/disable DP side),
> >    which means the resource is temporarily not available
> 
> Who invokes reset, I guess the controller (dwc3), so it ought to be
> aware of the reset condition.

No, it's not dwc3. It's TCPM. The USBDP PHY is a combo PHY with USB3
and Displayport. It supports muxing the USB and DP functionality
more or less arbitrary to 4 differential lanes, so it's registered
as a USB-C orientation-switch and mode-switch.

Thus the TCPM (Type-C Port Manager) will start to send mux requests
to the USBDP PHY. Going from USB3 only to USB+DP or vice versa
requires a reset affecting the USB3 controller.

> > 3. DWC3 accesses its registers during the reset -> SError, because PHY is off
> 
> I would assume that dwc3 should know about it as invoking entity..

It does not invoke it.

> > 
> > This series combined with the first patch of USBDP part 3 changes
> > things, so that it works like this:
> > 
> > 1. USBDP PHY provides critical resources to DWC3 USB controller
> > 2. USBDP PHY needs to reset to reconfigure (e.g. enable/disable DP side),
> >    which means the resource is temporarily not available
> > 3. USBDP PHY driver sends pre-reset notification
> > 4. DWC3 goes into a safe mode after receiving the pre-reset notifiaction
> > 5. USBDP PHY does the reset
> > 6. USBDP PHY reset finishes, USBDP PHY driver sends post-reset nofication
> > 7. DWC3 returns to normal mode after receiving the post-reset notification
> 
> > This avoids running into the SError.
> > 
> > Greetings,
> > 
> > -- Sebastian

Greetings from Prague,

-- Sebastian