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.g813d9a9188On 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!
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/
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
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!
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
© 2016 - 2026 Red Hat, Inc.