[PATCH net] net: stmmac: re-enable on-chip parity checkers for XGMAC ASP 0x2

[PATCH net] net: stmmac: re-enable on-chip parity checkers for XGMAC ASP 0x2

[Zxyan Zhu]

Commit 669a55560e4b ("net: stmmac: Check more MAC HW features for XGMAC
Core 3.20") made dwxgmac3_safety_feat_config() bail out early for
asp == 0x2, assuming that configuration has no parity protection.

Per the DWC_xgmac databook, the ASP field of MAC_HW_Feature3 selects:

  0x1 (AS_EPPE):  all automotive safety features, with ECC and parity
                  ports on the external application interface
  0x2 (AS_NEPPE): all automotive safety features, without ECC or
                  parity ports on the external application interface
  0x3 (AS_PPE):   all automotive safety features, with parity ports
                  on the external application interface

The reset value of the field is defined as:

  (DWCXG_ASP_ALL && DWCXG_ASP_PPE == 1) ? "3"
  : (DWCXG_ASP_ALL && DWCXG_ASP_PPE == 0) ? "2"
  : (DWCXG_ASP_ALL && DWCXG_ASP_PPE == 2) ? "1" : "0"

so ASP 0x2 implies DWCXG_ASP_ALL = 1, where the internal FSM state
parity and timeout (MAC_FSM_Control) and the on-chip data-path parity
(MTL_DPP_CONTROL) features exist; only the ports on the external
application interface are absent.  The early return therefore skips
enabling safety checkers that are present in the hardware.

Drop 0x2 from the condition so the FSM and data-path parity checkers
are enabled again.

Also update the safety feature descriptions printed by
stmmac_dma_cap_show() to spell out that ASP 0x1/0x2/0x3 differ only
in the ECC or parity ports on the external application interface; the
previous wording, "All Safety Features without ECC or Parity",
suggests the on-chip checkers are absent from an ASP 0x2 device.

Keep the early return for ASP 0x4 (EASP), which selects only ECC
protection for external memory and has no on-chip parity features.

Tested on XGMAC 3.10 and 3.40 cores.

Fixes: 669a55560e4b ("net: stmmac: Check more MAC HW features for XGMAC Core 3.20")
Cc: stable@vger.kernel.org
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 +++---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c   | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 1a88cbaed70c..6b2bfc241109 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -859,10 +859,10 @@ dwxgmac3_safety_feat_config(void __iomem *ioaddr, unsigned int asp,
 	value |= XGMAC_TCEIE; /* TSO Memory Correctable Error */
 	writel(value, ioaddr + XGMAC_DMA_ECC_INT_ENABLE);
 
-	/* 0x2: Without ECC or Parity Ports on External Application Interface
-	 * 0x4: Only ECC Protection for External Memory feature is selected
+	/* 0x4: Only ECC Protection for External Memory feature is
+	 * selected, without any on-chip parity protection
 	 */
-	if (asp == 0x2 || asp == 0x4)
+	if (asp == 0x4)
 		return 0;
 
 	/* 4. Enable Parity and Timeout for FSM */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 25894771e9e9..24f887df88fa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6741,9 +6741,9 @@ static int stmmac_dma_cap_show(struct seq_file *seq, void *v)
 	};
 	static const char * const dwxgmac_safety_feature_desc[] = {
 		"No",
-		"All Safety Features with ECC and Parity",
-		"All Safety Features without ECC or Parity",
-		"All Safety Features with Parity Only",
+		"All Safety Features with ECC and Parity Ports on External Application Interface",
+		"All Safety Features without ECC or Parity Ports on External Application Interface",
+		"All Safety Features with Parity Ports on External Application Interface",
 		"ECC Only",
 		"UNDEFINED",
 		"UNDEFINED",
-- 
2.34.1

Re: [PATCH net] net: stmmac: re-enable on-chip parity checkers for XGMAC ASP 0x2

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by LLM and not proven at runtime). If it was triggered
   please include the symptoms, like the stack trace or kernel messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account.

*IMPORTANT*: If you do repost (for other reasons) - please include
the relevant info in the cover letter or commit messages.
-- 
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net: stmmac: re-enable on-chip parity checkers for XGMAC ASP 0x2

[zhu xin]

The issue was triggered on real hardware during safety-feature
validation of an XGMAC integration: FSM state parity error injection
did not raise the expected safety interrupt.

There is no kernel log to quote for the failure itself -- the defect
is a silently skipped register write.

On XGMAC 3.10 and 3.40 cores, with the patch applied the checkers
come up enabled on ASP 0x2 devices and the same FSM parity error
injection now raises the safety interrupt as expected.

On Sat, Nov 14, 2026 at 9:58 AM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by LLM and not proven at runtime). If it was triggered
>    please include the symptoms, like the stack trace or kernel messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account.
>
> *IMPORTANT*: If you do repost (for other reasons) - please include
> the relevant info in the cover letter or commit messages.
> --
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.