Re: [PATCH v2] net: stmmac: enable MAC rx/tx after DMA start

[Abid Ali]

On Thu, 30 Jul 2026 16:07:15 -0700 Jakub Kicinski wrote:
> Looking at the patch - isn't it a bit awkward to handle Rx and Tx
> together? We want to keep Rx blocked to prevent incoming frames,
> but Tx should be allowed so that Tx can egress?

netif_tx_start_all_queues() runs after stmmac_mac_set() in both
__stmmac_open() and stmmac_xdp_open(), so no frame can be queued
in the window between DMA start and MAC enable. So I expect this
reorder to be fine and see no issue of coupling them together.

> Grepping around I'm not seeing any flushing of Tx. Aren't there
> issues with this driver if we stop the interface while it was
> paused by link partner?

I haven't run into these issues myself, but as Qingfang noted in
this thread the proper release sequence per the programming guide
needs more steps:

  stop TX DMA -> wait TPS (TX DMA stop confirmation) ->
  wait TX drain -> disable MAC RX/TX -> drain RX FIFO ->
  stop RX DMA -> wait RPS

This is a pre-existing gap in the driver, currently it just clears
the SR/ST bits for each channel and returns. Implementing the
proper sequence would need readl_poll_timeout on TPS/RPS status
bits per channel (up to 16 TX + 16 RX in my case), plus handling
timeouts if the status never updates in teardown.

The startup reorder is tested and verified to fix the RX hang I
have seen. Would it make sense to take this on its own (only the
startup reorder, with the teardown changes removed from v2) and
address the teardown at a later point as I see multiple open points
on what would be the right implementation to have there.

Thanks,
Abid