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

[Vinod Koul]

On 04-10-26, 14:44, Sebastian Reichel wrote:
> 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):

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?

> 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.

> 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..

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



-- 
~Vinod