Re: [PATCH phy-next 1/3] phy: lynx-28g: use timeouts when waiting for lane halt and reset

[Andrew Lunn <andrew@lunn.ch>]

On Sat, Mar 21, 2026 at 03:14:49AM +0200, Vladimir Oltean wrote:
> There are various circumstances in which a lane halt, or a lane reset,
> will fail to complete. If this happens, it will hang the kernel, which
> only implements a busy loop with no timeout.
> 
> The circumstances in which this will happen are all bugs in nature:
> - if we try to power off a powered off lane
> - if we try to power off a lane that uses a PLL locked onto the wrong
>   refclk frequency (wrong RCW, but SoC boots anyway)
> 
> Actually, unbounded loops in the kernel are a bad practice, so let's use
> read_poll_timeout() with a custom function that reads both LNaTRSTCTL
> (lane transmit control register) and LNaRRSTCTL (lane receive control
> register) and returns true when the request is done in both directions.
> 
> The HLT_REQ bit has to clear, whereas the RST_DONE bit has to get set.
> 
> Any time such an error happens, it is catastrophic and there is no point
> in trying to propagate it to our callers:
> - if lynx_28g_set_mode() -> lynx_28g_power_on() times out, we have
>   already reconfigured the lane, but returning an error would tell the
>   caller that we didn't
> - if lynx_28g_power_off() times out, again not much for the consumer to
>   do to help get out of this situation - the phy_power_off() call is
>   probably made from a context that the consumer can't cancel, or it is
>   making it to return to a known state from a previous failure.
> 
> So just print an error if timeouts happen and let the driver control
> flow continue. The entire point is just to not let the kernel freeze.
> 
> Suggested-by: Josua Mayer <josua@solid-run.com>
> Link: https://lore.kernel.org/lkml/d0c8bbf8-a0c5-469f-a148-de2235948c0f@solid-run.com/
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew