Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     netdev@vger.kernel.org
Cc:     "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Claudiu Manoil <claudiu.manoil@nxp.com>,
        linux-kernel@vger.kernel.org
Subject: [PATCH net] net: enetc: workaround for unresponsive pMAC after receiving express traffic
Date:   Tue, 11 Apr 2023 22:26:45 +0300
Message-Id: <20230411192645.1896048-1-vladimir.oltean@nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?k36rGFlTLtRVL74bVF8qEPABJ4Y0vSrBlo7hJ1myTYcPlO3hdU+ZCOvVmu0t?=
 =?us-ascii?Q?vB1I1FiC6ZgeZruq6D0Ixs0MllAvel2Jv5wrPQgj1cponGsftxUEUJpmO/Pc?=
 =?us-ascii?Q?LPtJU6v5Hi6BujQc2HGfQz1MSuFESP5ErsfHEBo5WDAjMs4/TuZTgB6tBvce?=
 =?us-ascii?Q?fNQ79kO471JjONFp8892AmawtdhLc3RXD506+zZkpbCYYX13ppOO0Dc67TbN?=
 =?us-ascii?Q?FUe0EPcpD34zh+gMElFbcEqNqWKi2DpdLFunolp0auUQQkSj9fU6F5XLGr8A?=
 =?us-ascii?Q?FASRFpolREj4oBCydrKKVrmP3Lzv32zVUdaIbGA2oXtOiXx24FkLfjLnHfqT?=
 =?us-ascii?Q?qg0Di8Q8Do7p2btMcuec9VoYYMSTgRXhaBOlcV7TBIQ8MwqtVjo5o6D3/xMA?=
 =?us-ascii?Q?AGdNw+KcLbBLDnNpphZi071bL3zZZmwE23HWu7idZ5mudJ6teZr0Czbk4YZT?=
 =?us-ascii?Q?0DM7rGAe9aAM7DQVLzTfqgrcKyGvERaBW1By0cW2xWNm2aSayTq0bu3hr4zH?=
 =?us-ascii?Q?aYdAbKfpdYZ9YtCKk1E3yBLVk/iOWKsnTlGfN8bqkYrmLdem+RyfeZH4xmg2?=
 =?us-ascii?Q?kf9p06byDCb4p+blKY1zbD22VLP/jC2+qYWmI7cy1plO5Ml9IemUXrV6OE5w?=
 =?us-ascii?Q?+FRi2+8Qa3wY68iRIV9+MNzo4NpEfItNQzZMMqxjdTB/hri2YoGSo4T6aUVp?=
 =?us-ascii?Q?8OD3vX1yCoz5cU+i8uNGKP39ZnQ6vSporaOWWl0Ga06u0cLnxUta+7t7W9D6?=
 =?us-ascii?Q?wy2qeQOkp9NdqJTl46eeHZtk1CDrEp6Fgkya6pVikboo3bTu6SkjWCvbvMps?=
 =?us-ascii?Q?TvHZbOPT5fSm1pi8e9PLDpmVYGe1IgnJYMduqqfVuSZh8B63J5CCuuVQXrhG?=
 =?us-ascii?Q?l+IyZXMWH4L1wH8NhsVXXSfYdhsNuHLkYOrMlAFm91Eef6k463OMKFXcsnSn?=
 =?us-ascii?Q?gX7f10IyAi62wI15LXy8zdJ/PoH+P5pA/rCtzGkWUT8fJP26vdj1L61Z8kTn?=
 =?us-ascii?Q?SfB3nDN0t21caLlErHBMdTO316782Cm84Vh/d1cyHcWfHveKYbffcsg67wCj?=
 =?us-ascii?Q?kkUHGcIZBSWOgT/NcNTZD8reUs5pkr5LgmUHItOcIH/3znHOlLu0ae2oH0Y2?=
 =?us-ascii?Q?cV4kgp+FFsVZUBd3j/fY6QhgK3YuHvBgCJbFfrz4kglZkJ62K2nVZMzo9kQk?=
 =?us-ascii?Q?djq+3R2IJmSYZHUlIhtTmeZ/ALjL/bfAX2G8iew6um+vKFSaUs9xWMiPrJpB?=
 =?us-ascii?Q?eLnAjEoe8ViugHtAw66O7JeKE4vZ5p2vTDwk+ZdjpG8LAZnbFfrSMT1u3bFD?=
 =?us-ascii?Q?nOeNi88Czn9ECVghBYTO5vnkufMKlEeas2HBuMul4PBHNaqRwUlBzei1gMrG?=
 =?us-ascii?Q?EPWaJelMbtlwxkKRhd+1qMnHqF2RntFX32kveXiCGThtVg+4ys+uUWJq7bxZ?=
 =?us-ascii?Q?IarCHbAscxs+2cVbl4Ix/XrsV+j9g/1cKLfhI3T3g5HRZyrSLHCdZabPIuGV?=
 =?us-ascii?Q?MropDgyrF2jKUEMNnuwbpO2fu6zTEKy6zD4dhr+OB0dr5pS9e9UOgiHAVLg0?=
 =?us-ascii?Q?6XmwXfs4G1q4MfAGTodYj/ndE+DrxZJccp7VrKmavBT28GUstjgaoNfYm9Hf?=
 =?us-ascii?Q?4Q=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cd9ecacd-9edb-44bb-22d3-08db3ac2b54e
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB6452.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2023 19:26:54.4853
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pe94Q7861ps+35Sps4qYZ4J1FoMmxg8qMCPpX9JqFWsCCxfc2AaZsW69eS3tbVYJ76X08j4UmT1/ZkO+34wGSA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR04MB7450
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

I have observed an issue where the RX direction of the LS1028A ENETC pMAC
seems unresponsive. The minimal procedure to reproduce the issue is:

1. Connect ENETC port 0 with a loopback RJ45 cable to one of the Felix
   switch ports (0).

2. Bring the ports up (MAC Merge layer is not enabled on either end).

3. Send a large quantity of unidirectional (express) traffic from Felix
   to ENETC. I tried altering frame size and frame count, and it doesn't
   appear to be specific to either of them, but rather, to the quantity
   of octets received. Lowering the frame count, the minimum quantity of
   packets to reproduce relatively consistently seems to be around 37000
   frames at 1514 octets (w/o FCS) each.

4. Using ethtool --set-mm, enable the pMAC in the Felix and in the ENETC
   ports, in both RX and TX directions, and with verification on both
   ends.

5. Wait for verification to complete on both sides.

6. Configure a traffic class as preemptible on both ends.

7. Send some packets again.

The issue is at step 5, where the verification process of ENETC ends
(meaning that Felix responds with an SMD-R and ENETC sees the response),
but the verification process of Felix never ends (it remains VERIFYING).

If step 3 is skipped or if ENETC receives less traffic than
approximately that threshold, the test runs all the way through
(verification succeeds on both ends, preemptible traffic passes fine).

If, between step 4 and 5, the step below is also introduced:

4.1. Disable and re-enable PM0_COMMAND_CONFIG bit RX_EN

then again, the sequence of steps runs all the way through, and
verification succeeds, even if there was the previous RX traffic
injected into ENETC.

Traffic sent *by* the ENETC port prior to enabling the MAC Merge layer
does not seem to influence the verification result, only received
traffic does.

The LS1028A manual does not mention any relationship between
PM0_COMMAND_CONFIG and MMCSR, and the hardware people don't seem to
know for now either.

The bit that is toggled to work around the issue is also toggled
by enetc_mac_enable(), called from phylink's mac_link_down() and
mac_link_up() methods - which is how the workaround was found:
verification would work after a link down/up.

Fixes: c7b9e8086902 ("net: enetc: add support for MAC Merge layer")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 .../net/ethernet/freescale/enetc/enetc_ethtool.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index da9d4b310fcd..838750a03cf6 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -989,6 +989,20 @@ static int enetc_get_mm(struct net_device *ndev, struct ethtool_mm_state *state)
 	return 0;
 }
 
+/* FIXME: Workaround for the link partner's verification failing if ENETC
+ * priorly received too much express traffic. The documentation doesn't
+ * suggest this is needed.
+ */
+static void enetc_restart_emac_rx(struct enetc_si *si)
+{
+	u32 val = enetc_port_rd(&si->hw, ENETC_PM0_CMD_CFG);
+
+	enetc_port_wr(&si->hw, ENETC_PM0_CMD_CFG, val & ~ENETC_PM0_RX_EN);
+
+	if (val & ENETC_PM0_RX_EN)
+		enetc_port_wr(&si->hw, ENETC_PM0_CMD_CFG, val);
+}
+
 static int enetc_set_mm(struct net_device *ndev, struct ethtool_mm_cfg *cfg,
 			struct netlink_ext_ack *extack)
 {
@@ -1040,6 +1054,8 @@ static int enetc_set_mm(struct net_device *ndev, struct ethtool_mm_cfg *cfg,
 
 	enetc_port_wr(hw, ENETC_MMCSR, val);
 
+	enetc_restart_emac_rx(priv->si);
+
 	mutex_unlock(&priv->mm_lock);
 
 	return 0;
-- 
2.34.1