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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Thu, Jan 08, 2026 at 07:08:09AM -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.

This is not SoCFPGA specific. The dwmac core only samples its
phy_intf_sel_i signals when coming out of reset, and then latches
that as the operating mode.

Currently, the dwmac core driver does not support dynamically changing
plat_dat->phy_interface at runtime. That may change in the future, but
as it requires a hardware reset which will clear out the PTP state, it
would need consideration of that effect.

The SoCFPGA driver only calls the set_phy_mode() methods from
socfpga_dwmac_init(), which in turn is called from the plat_dat->init
hook. This will be called from:

1. When stmmac_dvr_probe() is called, prior to allocating any
   resources, and prior to the core driver's first call to:
   reset_control_deassert(priv->plat->stmmac_ahb_rst);

2. As plat_dat->resume is not populated by the glue driver, the init
   hook will also be called when resuming from stmmac_resume().

Lastly, nothing in the main driver corrently writes to ->phy_interface.

I would like to see the platform glue drivers using more of what is
in the core driver, rather than re-inventing it, so I support the
idea of getting rid of dwmac->stmmac_ocp_rst.

What I suggest is to get rid of dwmac->stmmac_ocp_rst now.
devm_stmmac_probe_config_dt() will parse the device tree, looking for
the "ahb" reset, and assigning that to plat->stmmac_ahb_rst. If it
doesn't exist, then plat->stmmac-ahb_rst will be NULL.

So, in socfpga_dwmac_probe(), do something like this:

	struct reset_control *ocp_rst;
...
	if (!plat_dat->stmmac_ahb_rst) {
		ocp_rst = devm_reset_control_get_optional(dev, "stmmaceth-ocp");
		if (IS_ERR(ocp_rst))
			return dev_err_probe(dev, PTR_ERR(ocp_rst),
					     "failed to get ocp reset");

		if (ocp_rst)
			dev_warn(dev, "ocp reset is deprecated, please update device tree.\n");

		plat_dat->stmmac_ahb_rst = ocp_rst;
	}

Then, change all remaining instances of dwmac->stmmac_ocp_rst to
dwmac->plat_dat->stmmac_ahb_rst... and job done. You have compatibility
with device trees that use "ahb", and with device trees that use
"stmmaceth-ocp".

Given that struct socfpga_dwmac contains the plat_dat pointer, rather
than copying plat_dat->stmmac_rst to your private structure, please
use the one in the plat_dat structure.

The next question I have is - do you need to assert both the AHB reset
and stmmac_rst to set the PHY interface mode? I don't see a dependency
between these two resets in the socfpga code - the driver doesn't treat
them as nested. It asserts the AHB reset _then_ the stmmac reset, and
then releases them in the same order rather than reverse order. This
suggests there's no interdependence between them, and probably it's
only necessary to assert the stmmac core's reset (stmmac_rst).

So, maybe the driver can leave the handling of plat_dat->stmmac_ahb_rst
to the stmmac core code?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!