From: Simon Horman <horms@kernel.org>
To: Wei Fang <wei.fang@nxp.com>
Cc: claudiu.manoil@nxp.com, vladimir.oltean@nxp.com,
xiaoning.wang@nxp.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, linux@armlinux.org.uk, Frank.Li@nxp.com,
saikrishnag@marvell.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v5 RESEND net 0/3] net: enetc: safely reinitialize TX BD ring when it has unsent frames
Date: Wed, 25 Mar 2026 17:33:18 +0000 [thread overview]
Message-ID: <20260325173318.GJ111839@horms.kernel.org> (raw)
In-Reply-To: <20260324062121.2745033-1-wei.fang@nxp.com>
On Tue, Mar 24, 2026 at 02:21:18PM +0800, Wei Fang wrote:
> Currently the driver does not reset the producer index register (PIR) and
> consumer index register (CIR) when initializing a TX BD ring. The driver
> only reads the PIR and CIR and initializes the software indexes. If the
> TX BD ring is reinitialized when it still contains unsent frames, its PIR
> and CIR will not be equal after the reinitialization. However, the BDs
> between CIR and PIR have been freed and become invalid and this can lead
> to a hardware malfunction, causing the TX BD ring will not work properly.
>
> Since the PIR and CIR are sofeware-configurable on ENETC v4. Therefore,
> the driver must reset them if they are not equal when reinitializing
> the TX BD ring.
>
> However, resetting the PIR and CIR alone is insufficient, it cannot
> completely solve the problem. When a link-down event occurs while the TX
> BD ring is transmitting frames, subsequent reinitialization of the TX BD
> ring may cause it to malfunction. Because enetc4_pl_mac_link_down() only
> clears PMa_COMMAND_CONFIG[TX_EN] to disable MAC transmit data path. It
> doesn't set PORT[TXDIS] to 1 to flush the TX BD ring. Therefore, it is
> not safe to reinitialize the TX BD ring at this point.
>
> To safely reinitialize the TX BD ring after a link-down event, we checked
> with the NETC IP team, a proper Ethernet MAC graceful stop is necessary.
> Therefore, add the Ethernet MAC graceful stop to the link-down event
> handler enetc4_pl_mac_link_down(). Note that this patch set is not
> applicable to ENETC v1 (LS1028A).
>
> ---
> v5 link: https://lore.kernel.org/netdev/20260313094644.1132411-1-wei.fang@nxp.com/
> v5:
> 1. Add patch 3
> 2. Correct the typo in commit message of patch 1
> v4 link: https://lore.kernel.org/imx/20260312095415.669128-1-wei.fang@nxp.com/
> v4:
> Correct the offset of ENETC4_PSR
> v3 link: https://lore.kernel.org/imx/20260311084105.3982037-1-wei.fang@nxp.com/
> v3:
> 1. Split the v2 patch into two parts
> 2. Update the comments regarding PIR and CIR in enetc_setup_txbdr()
> 3. Use read_poll_timeout() instead of the while loop
> v2 link: https://lore.kernel.org/imx/20260309030412.2716984-1-wei.fang@nxp.com/
> v2:
> 1. Remove unused register macros (ENETC_SISR and SISR_TX_BUSY)
> 2. Remove spurious semicolon from enetc4_mac_wait_rx_empty()
For the series,
Reviewed-by: Simon Horman <horms@kernel.org>
prev parent reply other threads:[~2026-03-25 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 6:21 [PATCH v5 RESEND net 0/3] net: enetc: safely reinitialize TX BD ring when it has unsent frames Wei Fang
2026-03-24 6:21 ` [PATCH v5 RESEND net 1/3] net: enetc: reset PIR and CIR if they are not equal when initializing TX ring Wei Fang
2026-03-24 6:21 ` [PATCH v5 RESEND net 2/3] net: enetc: add graceful stop to safely reinitialize the TX Ring Wei Fang
2026-03-24 6:21 ` [PATCH v5 RESEND net 3/3] net: enetc: do not access non-existent registers on pseudo MAC Wei Fang
2026-03-25 17:33 ` Simon Horman [this message]
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=20260325173318.GJ111839@horms.kernel.org \
--to=horms@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=andrew+netdev@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saikrishnag@marvell.com \
--cc=vladimir.oltean@nxp.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox