Message-ID: <aWfBUPxvykOdygLO@shell.armlinux.org.uk>
Date: Wed, 14 Jan 2026 16:16:16 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: SHUKLA Mamta <mamta.shukla@...ca-geosystems.com>
Cc: Dinh Nguyen <dinguyen@...nel.org>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ahmad Fatoum <a.fatoum@...gutronix.de>,
	GEO-CHHER-bsp-development <bsp-development.geo@...ca-geosystems.com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-stm32@...md-mailman.stormreply.com" <linux-stm32@...md-mailman.stormreply.com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] net: stmmac: socfpga: add call to assert/deassert
 ahb reset line

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!

Powered by blists - more mailing lists