[PATCH v3 0/3] net: stmmac: socfpga: support both stmmaceth-ocp and ahb reset names

[PATCH v3 0/3] net: stmmac: socfpga: support both stmmaceth-ocp and ahb reset names

[Dinh Nguyen]

The dwmac-socfpga stmmac ethernet controller supports 2 standard reset
lines, named "stmmaceth" and "stmmaceth-ocp". At the time of upstreaming
support for the platform, the "stmmaceth-ocp" name was used for the 2nd
reset name. We later realized that the "stmmaceth-ocp" reset name is
the same as the "ahb" name that is used by the standard stmmac driver.
But since the "stmmaceth-ocp" name support has already been introduced
to the wild, it cannot just be removed from the driver, thus we can
modify the driver to support both "stmmaceth-ocp" and "ahb", with the
idea that "ahb" will be used going forward.

This series add the support to call reset assert/de-assert both "abh"
and "stmmaceth-ocp" to the dwmac-socfpga platform driver, then reverts
the patch that uses the DTS "stmmaceth-ocp" reset name.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
Changes in v3:
- Edit dt-bindings patch to just remove TODO note
- Link to v2: https://lore.kernel.org/r/20260105-remove_ocp-v2-0-4fa2bda09521@kernel.org

Changes in v2:
- Added a dt-binding patch to mark 'stmmaceth-ocp' as deprecated
- Link to v1: https://lore.kernel.org/r/20251229-remove_ocp-v1-0-594294e04bd4@kernel.org

---
Dinh Nguyen (3):
      net: stmmac: socfpga: add call to assert/deassert ahb reset line
      Revert "arm: dts: socfpga: use reset-name "stmmaceth-ocp" instead of "ahb""
      dt-bindings: net: altr,socfpga-stmmac: remove TODO note

 Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml | 2 --
 arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi           | 6 +++---
 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c            | 4 ++++
 3 files changed, 7 insertions(+), 5 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251229-remove_ocp-44786389b052

Best regards,
-- 
Dinh Nguyen <dinguyen@kernel.org>

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

[Dinh Nguyen]

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@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);
 	reset_control_assert(dwmac->stmmac_rst);
 
 	regmap_read(sys_mgr_base_addr, reg_offset, &ctrl);
@@ -436,6 +437,7 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
 	 * the enet controller, and operation to start in requested mode
 	 */
 	reset_control_deassert(dwmac->stmmac_ocp_rst);
+	reset_control_deassert(dwmac->plat_dat->stmmac_ahb_rst);
 	reset_control_deassert(dwmac->stmmac_rst);
 	if (phymode == PHY_INTERFACE_MODE_SGMII)
 		socfpga_sgmii_config(dwmac, true);
@@ -463,6 +465,7 @@ static int socfpga_gen10_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);
 	reset_control_assert(dwmac->stmmac_rst);
 
 	regmap_read(sys_mgr_base_addr, reg_offset, &ctrl);
@@ -489,6 +492,7 @@ static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
 	 * the enet controller, and operation to start in requested mode
 	 */
 	reset_control_deassert(dwmac->stmmac_ocp_rst);
+	reset_control_deassert(dwmac->plat_dat->stmmac_ahb_rst);
 	reset_control_deassert(dwmac->stmmac_rst);
 	if (phymode == PHY_INTERFACE_MODE_SGMII)
 		socfpga_sgmii_config(dwmac, true);

-- 
2.42.0.411.g813d9a9188

Re: [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@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

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

[Russell King (Oracle)]

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!

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

[Dinh Nguyen]

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/

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

[SHUKLA Mamta]

Hello Dinh,

On 1/13/26 22:37, Dinh Nguyen wrote:
>
> 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.

On Arria10 socfpga, both reset lines i.e stmmac_ocp_rst and stmmac_rst 
are needed since EMAC Controller on Arria10 supports Tx Rx FIFO with ECC

RAM and as per datasheet[1]:

`An EMAC ECC RAM reset asserts a reset to both the memory and the 
multiplexed EMAC bus interface clock, ap_clk. You should ensure that 
both the EMAC ECC RAM and the EMAC Module resets are deasserted before 
beginning transactions. Program the emac*ocp bits and the emac* bits in 
the per0modrst register of the Reset Manager to deassert reset in the 
EMAC's ECC RAM and the EMAC module, respectively.`

[1]https://docs.altera.com/r/docs/683711/22.3/intel-arria-10-hard-processor-system-technical-reference-manual/taking-the-ethernet-mac-out-of-reset


OTOH, we can't have both scp and ahb rst together while setting phy 
mode, since they are basically same reset lines and having both leads to 
warning:

[    0.742218] CAN device driver interface
[    0.746401] socfpga-dwmac ff800000.ethernet: IRQ eth_wake_irq not found
[    0.753018] socfpga-dwmac ff800000.ethernet: IRQ eth_lpi not found
[    0.759177] socfpga-dwmac ff800000.ethernet: IRQ sfty not found
[    0.765159] socfpga-dwmac ff800000.ethernet: Deprecated MDIO bus 
assumption used
[    0.772674] ------------[ cut here ]------------
[    0.777278] WARNING: /drivers/reset/core.c:457 at 
reset_control_assert+0x178/0x1f8, CPU#0: swapper/0/1
[    0.786585] Modules linked in:
[    0.789638] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
6.19.0-rc3-00262-g36d53f861448 #1 PREEMPT
[    0.789652] Hardware name: Altera SOCFPGA Arria10
[    0.789657] Call trace:
[    0.789666]  unwind_backtrace from show_stack+0x18/0x1c
[    0.789688]  show_stack from dump_stack_lvl+0x54/0x68
[    0.789703]  dump_stack_lvl from __warn+0x98/0x180
[    0.789719]  __warn from warn_slowpath_fmt+0x1bc/0x1c4
[    0.789733]  warn_slowpath_fmt from reset_control_assert+0x178/0x1f8
[    0.789749]  reset_control_assert from 
socfpga_gen10_set_phy_mode+0xec/0x1f4
[    0.789776]  socfpga_gen10_set_phy_mode from stmmac_dvr_probe+0x40/0x1154
[    0.789804]  stmmac_dvr_probe from devm_stmmac_pltfr_probe+0x34/0xa8
[    0.789825]  devm_stmmac_pltfr_probe from socfpga_dwmac_probe+0x160/0x1b8
[    0.789847]  socfpga_dwmac_probe from platform_probe+0x64/0x98
[    0.789875]  platform_probe from really_probe+0xc0/0x2bc
[    0.789896]  really_probe from __driver_probe_device+0x90/0x1a4
[    0.789913]  __driver_probe_device from driver_probe_device+0x38/0x10c
[    0.789931]  driver_probe_device from __driver_attach+0x98/0x180
[    0.789948]  __driver_attach from bus_for_each_dev+0x84/0xd4
[    0.789965]  bus_for_each_dev from bus_add_driver+0xd4/0x1f4
[    0.789980]  bus_add_driver from driver_register+0x84/0x11c
[    0.789998]  driver_register from do_one_initcall+0x60/0x270
[    0.790015]  do_one_initcall from kernel_init_freeable+0x228/0x294
[    0.790036]  kernel_init_freeable from kernel_init+0x24/0x138
[    0.790055]  kernel_init from ret_from_fork+0x14/0x28
[    0.790069] Exception stack(0xd202dfb0 to 0xd202dff8)
[    0.790078] dfa0:                                     00000000 
00000000 00000000 00000000
[    0.790087] dfc0: 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000
[    0.790094] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    0.790100] ---[ end trace 0000000000000000 ]---
[    0.963016] socfpga-dwmac ff800000.ethernet: User ID: 0x10, Synopsys 
ID: 0x37
[    0.970148] socfpga-dwmac ff800000.ethernet:     DWMAC1000
[    0.976025] socfpga-dwmac ff800000.ethernet: DMA HW capability 
register supported
[    0.983511] socfpga-dwmac ff800000.ethernet: RX Checksum Offload 
Engine supported

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

---

Mamta

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

[Russell King (Oracle)]

On Wed, Jan 14, 2026 at 02:09:27PM +0000, SHUKLA Mamta wrote:
> Hello Dinh,
> 
> On Arria10 socfpga, both reset lines i.e stmmac_ocp_rst and stmmac_rst 
> are needed since EMAC Controller on Arria10 supports Tx Rx FIFO with ECC
> 
> RAM and as per datasheet[1]:
> 
> `An EMAC ECC RAM reset asserts a reset to both the memory and the 
> multiplexed EMAC bus interface clock, ap_clk. You should ensure that 
> both the EMAC ECC RAM and the EMAC Module resets are deasserted before 
> beginning transactions. Program the emac*ocp bits and the emac* bits in 
> the per0modrst register of the Reset Manager to deassert reset in the 
> EMAC's ECC RAM and the EMAC module, respectively.`
> 
> [1]https://docs.altera.com/r/docs/683711/22.3/intel-arria-10-hard-processor-system-technical-reference-manual/taking-the-ethernet-mac-out-of-reset

Let's look at exactly what this is saying.

"An EMAC ECC RAM reset asserts a reset to both the memory and the
multiplexed EMAC bus interface clock, ap_clk."

1. Asserting the EMAC ECC RAM reset asserts reset to two items:
    - memory
    - the EMAC bus interface clock, ap_clk.
   This is not referring to any other modules, but it does suggest that
   the bus clock will be affected in some way, potentially stopping the
   clock.

"You should ensure that both the EMAC ECC RAM and the EMAC Module resets
are deasserted before beginning transactions."

2. This states that both resets (EMAC ECC RAM and EMAC module) need to
   be deasserted in order to access the EMAC. This is logical.

   If the EMAC ECC RAM reset is asserted, then, because it affects the
   bus interface clock, this may mean that accesses over the APB bus
   can not be performed because there could be no clock to allow them
   to complete. Thus attempting an access will probably stall the
   processor. (We've seen SoCs where this happens.)

   As having the DWMAC reset asserted means that the entire DWMAC
   hardware would be held in reset, including the bus interface,
   meaning that it will not respond to accesses. Whether that also
   hangs the processor is questionable, because APB has error reporting.

"Program the emac*ocp bits and the emac* bits in the per0modrst register
of the Reset Manager to deassert reset in the EMAC's ECC RAM and the EMAC
module, respectively.`

3. This states where the reset bits allegedly are in the register set.
   There is a link to https://docs.altera.com/r/docs/683711/22.3/intel-arria-10-hard-processor-system-technical-reference-manual/module-reset-signals
   but interestingly, the per0modrst (which implies per0 group) doesn't
   list emac*ocp resets. In fact, there is only one reference to "ocp"
   on that web page, which is in a diagram of the reset controller,
   specifically its bus interface.

So, the quoted section doesn't state anything about the requirements for
resetting the dwmac core.

What it does state is that both resets need to be deasserted before any
access is made, which is reasonable.

> OTOH, we can't have both scp and ahb rst together while setting phy 
> mode, since they are basically same reset lines and having both leads to 
> warning:

So it seems that you actually have a single reset bit, and you have
that represented as a single shared reset - shared between your
"stmamc_rst" and "stmmac_ocp_rst".

I notice Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
doesn't describe the resets, but has:
  # TODO: Determine how to handle the Arria10 reset-name, stmmaceth-ocp, that
  # does not validate against net/snps,dwmac.yaml.

as dwmac describes at least one reset between one called "stmmaceth"
and the other called "ahb".

The only possibility I see for these "EMAC ECC RAM" resets are in
Table 25.  RAM Clear Group, Generated Module Resets, there's a bunch
of signals described there "emacN(tx|rx)_sec_ram_rst_n, and that
table suggests that these resets are asserted and deasserted on
cold and warm system level resets.

Given that there seems to be no way for software to control these
EMAC ECC RAM resets, they seem to be outside the realm of needing
to be handled within the driver, and also should not be described
in DT.

Maybe I missed something?

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

[PATCH v3 2/3] Revert "arm: dts: socfpga: use reset-name "stmmaceth-ocp" instead of "ahb""

[Dinh Nguyen]

This reverts commit 62a40a0d5634834790f7166ab592be247390d857.

With the patch "add call to assert/deassert ahb reset line" in place, we can
safely remove the "stmmaceth-ocp" reset name and just use the standard
"ahb" reset name.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi b/arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi
index b108265e9bde4..6b6e77596ffa8 100644
--- a/arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/intel/socfpga/socfpga_arria10.dtsi
@@ -440,7 +440,7 @@ gmac0: ethernet@ff800000 {
 			clocks = <&l4_mp_clk>, <&peri_emac_ptp_clk>;
 			clock-names = "stmmaceth", "ptp_ref";
 			resets = <&rst EMAC0_RESET>, <&rst EMAC0_OCP_RESET>;
-			reset-names = "stmmaceth", "stmmaceth-ocp";
+			reset-names = "stmmaceth", "ahb";
 			snps,axi-config = <&socfpga_axi_setup>;
 			status = "disabled";
 		};
@@ -460,7 +460,7 @@ gmac1: ethernet@ff802000 {
 			clocks = <&l4_mp_clk>, <&peri_emac_ptp_clk>;
 			clock-names = "stmmaceth", "ptp_ref";
 			resets = <&rst EMAC1_RESET>, <&rst EMAC1_OCP_RESET>;
-			reset-names = "stmmaceth", "stmmaceth-ocp";
+			reset-names = "stmmaceth", "ahb";
 			snps,axi-config = <&socfpga_axi_setup>;
 			status = "disabled";
 		};
@@ -480,7 +480,7 @@ gmac2: ethernet@ff804000 {
 			clocks = <&l4_mp_clk>, <&peri_emac_ptp_clk>;
 			clock-names = "stmmaceth", "ptp_ref";
 			resets = <&rst EMAC2_RESET>, <&rst EMAC2_OCP_RESET>;
-			reset-names = "stmmaceth", "stmmaceth-ocp";
+			reset-names = "stmmaceth", "ahb";
 			snps,axi-config = <&socfpga_axi_setup>;
 			status = "disabled";
 		};

-- 
2.42.0.411.g813d9a9188

[PATCH v3 3/3] dt-bindings: net: altr,socfpga-stmmac: remove TODO note

[Dinh Nguyen]

The 'stmmaceth-ocp' will no longer be used as a reset-name, going forward
and 'ahb' shall be used.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v3: Addressed Rob Herring's comments and updated commit header/message
v2: Introduced
v1: n/a
---
 Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
index fc445ad5a1f1a..8e7077d4319eb 100644
--- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
+++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
@@ -13,8 +13,6 @@ description:
   This binding describes the Altera SOCFPGA SoC implementation of the
   Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, Agilex5 and Agilex7
   families of chips.
-  # TODO: Determine how to handle the Arria10 reset-name, stmmaceth-ocp, that
-  # does not validate against net/snps,dwmac.yaml.
 
 select:
   properties:

-- 
2.42.0.411.g813d9a9188

Re: [PATCH v3 3/3] dt-bindings: net: altr,socfpga-stmmac: remove TODO note

[Rob Herring (Arm)]

On Thu, 08 Jan 2026 07:08:11 -0600, Dinh Nguyen wrote:
> The 'stmmaceth-ocp' will no longer be used as a reset-name, going forward
> and 'ahb' shall be used.
> 
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> v3: Addressed Rob Herring's comments and updated commit header/message
> v2: Introduced
> v1: n/a
> ---
>  Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml | 2 --
>  1 file changed, 2 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>