Re: [PATCH v16 1/6] phy: core: add notifier infrastructure

[Sebastian Reichel]

Hello Vinod,

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):

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. DWC3 accesses its registers during the reset -> SError, because PHY is off

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

Attachment: signature.asc
Description: PGP signature