Re: [PATCH 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

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

On Sun, Mar 02, 2025 at 09:20:49PM +0000, Lad, Prabhakar wrote:
> Hi Russell,
> > What is the reason for setting this flag? If it's because of suspend/
> > resume failures, does my "net: stmmac: fix resume failures due to
> > RX clock" series solve this for you without requiring this flag?
> >
> Ive set this flag based on the configuration supported by this IP.
> Unfortunately the platform which I am working on doesn't support s2r
> yet so I cannot test suspend/resume path yet. But I do see an issue
> when I unload and load just the glue module the DMA reset fails.

Thanks for that feedback - that's a scenario I hadn't considered.

I was trying to avoid having to disable LPI RX clock-stop on suspend by
ensuring that it was enabled at resume time. I think that's valid, but
you've brought up another similar scenario:

- device is brought up, configures RX clock stop
- links with media, negotiates EEE
- driver is unloaded, link doesn't go down, but due to no traffic goes
  into idle, so RX clock is stopped
- driver reloaded, RX clock still stopped, reset fails

I would like to solve that so we can get the power savings from
stopping the clock, but still have reset work when necessary.

I'm guessing that the "DMA reset fails" refers to this path:

stmmac_open() -> __stmmac_open() -> stmmac_hw_setup() ->
stmmac_init_dma_engine() -> stmmac_reset() ?

In other words, when the device is being brought back up
adminsitratively?

What happens if you (replace $if):

# ip li set dev $if down
# ip li set dev $if up

Does that also fail without STMMAC_FLAG_RX_CLK_RUNS_IN_LPI set?

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