[PATCH v3 1/3] net: stmmac: socfpga: add call to assert/deassert ahb reset line

[Philipp Zabel]

On Do, 2026-01-08 at 07:08 -0600, Dinh Nguyen wrote:
> The "stmmaceth-ocp" reset line of stmmac controller on the SoCFPGA
> platform is essentially the "ahb" reset on the standard stmmac
> controller. But since stmmaceth-ocp has already been introduced into
> the wild, we cannot just remove support for it. But what we can do is
> to support both "stmmaceth-ocp" and "ahb" reset names. Going forward we
> will be using "ahb", but in order to not break ABI, we will be call reset
> assert/de-assert both ahb and stmmaceth-ocp.
> 
> The ethernet hardware on SoCFPGA requires either the stmmaceth-ocp or
> ahb reset to be asserted every time before changing the phy mode, then
> de-asserted when the phy mode has been set.
> 
> With this change, we should be able to revert patch:
> commit 62a40a0d5634 ("arm: dts: socfpga: use reset-name "stmmaceth-ocp"
> instead of "ahb"")
> 
> Signed-off-by: Dinh Nguyen <dinguyen at kernel.org>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index a2b52d2c4eb6f..79df55515c718 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -407,6 +407,7 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
>  
>  	/* Assert reset to the enet controller before changing the phy mode */
>  	reset_control_assert(dwmac->stmmac_ocp_rst);
> +	reset_control_assert(dwmac->plat_dat->stmmac_ahb_rst);

Since these two are just different names for the same reset,
I think it would be cleaner to rename dwmac->stmmac_ocp_rst to
dwmac->stmmac_ahb_rst and assign this either to
dwmac->plat_dat->stmmac_ahb_rst or to the stmmac-ocp reset during
probe.

Also, a comment explaining that the dem_reset_control_get_optional(dev,
"stmmaceth-ocp") is for backwards compatibility with legacy device
trees could be helpful to future readers.


regards
Philipp