All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abid Ali <dev.taqnialabs@gmail.com>
To: andrew@lunn.ch
Cc: alexandre.torgue@foss.st.com, andrew+netdev@lunn.ch,
	davem@davemloft.net, dev.taqnialabs@gmail.com,
	edumazet@google.com, kuba@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
	pabeni@redhat.com
Subject: Re: [PATCH] net: stmmac: enable MAC rx/tx after DMA start
Date: Mon, 27 Jul 2026 05:57:15 +0000	[thread overview]
Message-ID: <20260727055715.4430-1-dev.taqnialabs@gmail.com> (raw)
In-Reply-To: <ee639271-60dd-49f7-9e77-0ae47841754d@lunn.ch>

On Sun, Jul 26, 2026 at 18:15:20 +0000, Andrew Lunn wrote:
> There should be a function which is the opposite of stmmac_hw_setup(),
> which tears it down. What order are things done there? tear down is
> generally done in the opposite order to setup, so does the "Disable
> the MAC Rx/Tx" also need to move?

I have not seen the FIFO stall in the teardown in my testing,
but the MAC Rx/Tx should be disabled before the DMA engine is stopped.
For the normal path (__stmmac_release), phylink_stop() is called first
which triggers stmmac_mac_link_down() -> stmmac_mac_set(false), so the
MAC is already disabled before stmmac_stop_all_dma(). The teardown
order is already correct there.

> Same comment for the opposite of stmmac_xdp_open().

Currently, stmmac_xdp_release() does:

    stmmac_stop_all_dma(priv);
    ...
    stmmac_mac_set(priv, priv->ioaddr, false);

The ordering is not followed here,  I'll make it follow the similar
ordering to (__stmmac_release) in v2.

Thanks,
Abid



  reply	other threads:[~2026-07-27  5:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 12:04 [PATCH] net: stmmac: enable MAC rx/tx after DMA start Abid Ali via B4 Relay
2026-07-26 12:04 ` Abid Ali
2026-07-26 18:15 ` Andrew Lunn
2026-07-27  5:57   ` Abid Ali [this message]
2026-07-27 13:03     ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260727055715.4430-1-dev.taqnialabs@gmail.com \
    --to=dev.taqnialabs@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.