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

[Dinh Nguyen <dinguyen@kernel.org>]

On 1/8/26 10:10, Russell King (Oracle) wrote:
> 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?
> 

Thanks for the suggestion. According to this commit[1], it seems that 
both reset lines need to get toggled. But I'm going to run some test on 
HW and make the appropriate changes.

Dinh

[1] 
https://lore.kernel.org/all/20250205134428.529625725@linuxfoundation.org/