[PATCH v2 net 0/2] net: enetc: restore RX ring congestion mode after ring reconfiguration

wei.fang@oss.nxp.com posted 2 patches 1 month, 1 week ago
drivers/net/ethernet/freescale/enetc/enetc.c  | 72 +++++++++++++++----
drivers/net/ethernet/freescale/enetc/enetc.h  |  9 +++
.../net/ethernet/freescale/enetc/enetc4_pf.c  | 16 ++---
.../net/ethernet/freescale/enetc/enetc_pf.c   | 14 +---
4 files changed, 72 insertions(+), 39 deletions(-)
[PATCH v2 net 0/2] net: enetc: restore RX ring congestion mode after ring reconfiguration
Posted by wei.fang@oss.nxp.com 1 month, 1 week ago
From: Wei Fang <wei.fang@nxp.com>

The RX BD ring congestion mode (CM) enables the ENETC MAC to generate
PAUSE frames when ingress congestion occurs. It is configured only in
the phylink .mac_link_up() callback, which is invoked when the link
status changes.

However, enetc_reconfigure() tears down and re-creates the RX BD rings
at runtime without any link status change, for example when enabling or
disabling PTP RX hardware timestamping. enetc_setup_rxbdr() rebuilds the
RBMR register from zero, which clears the CM bit, and since the link
status does not change, .mac_link_up() is not called again to restore
it. As a result, flow control silently stops working after such a
reconfiguration.

To solve this issue, track the desired CM state in a software flag
ENETC_RXBDR_CM, which is maintained by the .mac_link_up() /
.mac_link_down() callbacks and consulted by enetc_setup_rxbdr() when the
RX BD rings are (re)configured. Both ENETC v1 and ENETC v4 are affected
and are fixed in the same way.

---
v2:
1. Add a generic helper enetc_set_congestion_mode() to set the
   congestion mode of the SI's RX BD rings
2. Move the setting of ENETC_RBMR from enetc_setup_rxbdr() to
   enetc_enable_rxbdr()
3. Add gen_lock to struct enetc_si to prevent concurrent access to
   ENETC_RBMR and the ENETC_RXBDR_CM bit of priv->flags
v1 link: https://lore.kernel.org/imx/20260728023217.2499420-1-wei.fang@oss.nxp.com/
---

Wei Fang (2):
  net: enetc: restore RX ring congestion mode after ring reconfiguration
  net: enetc: restore RX ring congestion mode for ENETC v4

 drivers/net/ethernet/freescale/enetc/enetc.c  | 72 +++++++++++++++----
 drivers/net/ethernet/freescale/enetc/enetc.h  |  9 +++
 .../net/ethernet/freescale/enetc/enetc4_pf.c  | 16 ++---
 .../net/ethernet/freescale/enetc/enetc_pf.c   | 14 +---
 4 files changed, 72 insertions(+), 39 deletions(-)

-- 
2.34.1
Re: [PATCH v2 net 0/2] net: enetc: restore RX ring congestion mode after ring reconfiguration
Posted by Simon Horman 1 month ago
On Fri, Aug 21, 2026 at 02:41:38PM +0800, wei.fang@oss.nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
> 
> The RX BD ring congestion mode (CM) enables the ENETC MAC to generate
> PAUSE frames when ingress congestion occurs. It is configured only in
> the phylink .mac_link_up() callback, which is invoked when the link
> status changes.
> 
> However, enetc_reconfigure() tears down and re-creates the RX BD rings
> at runtime without any link status change, for example when enabling or
> disabling PTP RX hardware timestamping. enetc_setup_rxbdr() rebuilds the
> RBMR register from zero, which clears the CM bit, and since the link
> status does not change, .mac_link_up() is not called again to restore
> it. As a result, flow control silently stops working after such a
> reconfiguration.
> 
> To solve this issue, track the desired CM state in a software flag
> ENETC_RXBDR_CM, which is maintained by the .mac_link_up() /
> .mac_link_down() callbacks and consulted by enetc_setup_rxbdr() when the
> RX BD rings are (re)configured. Both ENETC v1 and ENETC v4 are affected
> and are fixed in the same way.
> 
> ---
> v2:
> 1. Add a generic helper enetc_set_congestion_mode() to set the
>    congestion mode of the SI's RX BD rings
> 2. Move the setting of ENETC_RBMR from enetc_setup_rxbdr() to
>    enetc_enable_rxbdr()
> 3. Add gen_lock to struct enetc_si to prevent concurrent access to
>    ENETC_RBMR and the ENETC_RXBDR_CM bit of priv->flags
> v1 link: https://lore.kernel.org/imx/20260728023217.2499420-1-wei.fang@oss.nxp.com/

Thanks for the updates.

The AI-generated reviews provided by sashiko-bot elsewhere in this
thread appear to relate to pre-existing issues that I don't believe
should impact the progress of this patch.

For the series:
Reviewed-by: Simon Horman <horms@kernel.org>