Hi,

On 7/18/26 09:35, tresonic wrote:

Thank you for you explanations!

quoted

The interrupt is being enabled in the init_chan call in
stmmac_dma_ops. Ideally, it should be disabled in a mirror function,
which currently does not exist. So maybe deinit_chan() needs
adding. But where to call it from? init_chan() is called from
stmmac_init_dma_engine(), from stmmac_hw_setup(). stmmac_resume() does
call this. So we need something in stmmac_suspend(). Maybe in
stmmac_stop_all_dma()?

stmmac is messy, there are often not mirror functions. If there is a
stmmac_init_dma_engine() there should be
stmmac_deinit_dma_engine(). If there is stmmac_hw_setup() there should
be stmmac_hw_tairdown(). But none of these seem to exist. 

(sorry I missed that thread, I was on my  way back from netdev)

quoted

Anyway, do you want to try to implement deinit_chan() and call it from
stmmac_stop_all_dma()?

Yes I'd really like to implement a solution here.
This is my try, but I still have some questions:
- is it ok to disable all interrupts on deinit_chan()?

It mirrors the init, so it should be fine. Now I'm not sure how that
will interfere with things like WoL though, I've yet to test this.

- maybe the interrupt could also just be disabled in stop_rx?

I don't think so, if something is missing w.r.t the interrupts being
enabled when they shouldn't, that would need to be addressed in the
xdp part, as this seems to be the only place where stop_rx is called
without the dma_chan interrupts being masked.

[...]

I've given this patch a test on imx8mp (that has a dwmac4.10), no regressions found
from running basic tests :) I think this is a good fix, if you submit it can you
address both dwmac410 and dwmac4 ? They both should be impacted by that problem.

Maxime