From:   Joakim Zhang <qiangqing.zhang@nxp.com>
To:     davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
        rmk+kernel@arm.linux.org.uk
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-imx@nxp.com
Subject: [PATCH net V2] net: fec: only clear interrupt of handling queue in fec_enet_rx_queue()
Date:   Mon,  6 Dec 2021 21:54:57 +0800
Message-Id: <20211206135457.15946-1-qiangqing.zhang@nxp.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ZqtsrstDEvuD3gBZyqXLDsuF2cPopeG/86ennRkkhFJNnFlFcEI8ml57ZZvN?=
 =?us-ascii?Q?WAz1fHJH2GQwOYD/HhZfUg9FQE43GIkpP2G7Vgvcj2mOg6bQa+3U3n3x0Sii?=
 =?us-ascii?Q?XXmEJfPcbBNZBrvCIRnxAnARXhGNNhE+YhKV4Zq9hZL9OTNxbEtglQf4YuCG?=
 =?us-ascii?Q?HegLFXA0EPeSsKKx+l/JBcbObEw3GEU3UUuBnT+xmEtTg+TYntEcx0wsCjzM?=
 =?us-ascii?Q?GnrA8HmYh4GsHRTYCeC0/iW308YYxbyqVafrBsnPA6xdPBi65lSZ9Ut6OToP?=
 =?us-ascii?Q?LuZ2MilLazJy/EA2haNVwcIEpgO9gG59VW/ro/4BuoYm1sMggcIIwXaJ8Aam?=
 =?us-ascii?Q?0a2yLdAcIi2tHdLDADGBAg4yp6l8g0nXQGEJ6gTFQJAW3rbg1Z9JAKbAfNdx?=
 =?us-ascii?Q?ylOVC6WesK1V9JZsGgslxUGdU/pHv/jb2LiFEtkoWsllj7R6mNnGnP31nqxe?=
 =?us-ascii?Q?YR/NnBcURHvZgZNR3Xpd42hD8X4qhtu2LNF0WNeUa8ScF+UhBCQt0tvmLxRM?=
 =?us-ascii?Q?47WbSiC7RoJk31Ur7QhZurZuUFhVMB0L0qwmFyP3XxlziXtSry6omH0b+qF9?=
 =?us-ascii?Q?tvjkLiVwkhKzTA5OT1o63zPjEK0a2LyywxerhuwJwGwt8idXZP1u9KnIe71V?=
 =?us-ascii?Q?rNsw3rZjN3snsuwIS+gjAADmkxC2OgwVIsjgRKT920U0h9Ta22ApuNN+9WWS?=
 =?us-ascii?Q?7Ff2+tsExO7IrDBCdFPsT5YHwxJLzR3dr/B9LmsljF535OGmPEiEM/y984/H?=
 =?us-ascii?Q?dlLhSizwUPs3Y2HT1nHKF4V/bTqiwTZYd4cMTPhLKCg4sfSCtQgf/IJv0Dav?=
 =?us-ascii?Q?z+cQyQzq9t/3aJn0s1mmzEsNlQIlKmzcfqv+BwyBjzLx47d5gn21mYHM/Xjt?=
 =?us-ascii?Q?fNsPuLiL4CJEOyIvgqm9AhBZ2TyBNKY9Qsfxu8+mRj5/Hso5Pu6wqvVysV9o?=
 =?us-ascii?Q?xxJRBWpWbNLq+YIjEKnSydjS2m5lRNYNMxiWl2Bgv9junTtMMXsfriNbboRO?=
 =?us-ascii?Q?Dk5ryyETIpoGweMgcRlHw/f5ZW4ePdeQpOACqttrzsvABQ+Ks86e6csOWtJ+?=
 =?us-ascii?Q?OqaRQ/Wey2ZIjhi0TaKNh2AVNaNQtBlzxvY8EWF22QBMABCZuc+A95LrKfG5?=
 =?us-ascii?Q?gGDesaQJPwi53oyNq7IjSybqpVGWrGR5bjUBsU+aYH2SQIMPHkbSx0cseuBH?=
 =?us-ascii?Q?BnALmgci5s7GkMAakNGBzRqpM1S0/tZ5BzqaR0YzZ2R23XRP6hePh2JIVcE/?=
 =?us-ascii?Q?E3XraXEI4ESlFvaSQu9oZQHa6rjf1XvLjS5SvpxZoEeueaBR+cVeSlk+YsM4?=
 =?us-ascii?Q?t0AWnXWjNHOqymdzxxexjpYhvHrJM/uBVladb3ZO1pYeCWIxNqdvuoOu7E/B?=
 =?us-ascii?Q?+uYraN/fkjIBELaZrZpwwvLpWo44gVfaOjjzLtLhZ4PVBqy2e8Ha6exXneIE?=
 =?us-ascii?Q?KBC6nq3H4pCfIVB7gkdh+gu5dvR7pxId0TBqGa6miphrXRBxHYUratDb2XWT?=
 =?us-ascii?Q?+p7tWQ5wp8RMapFYu4Ba5GXNYM17NSV0znRU+2Yf5pqUIzmpP5IWdB+jXqG8?=
 =?us-ascii?Q?4lsndx524V+cMJAV7QTIFxNNLJi401C+VdZm8g22p7Njbtj40y5kMybEfRGe?=
 =?us-ascii?Q?GjvD/BmGFd8/8ztR/q2MGSw=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0151582-bca2-4270-d471-08d9b8c00db0
X-MS-Exchange-CrossTenant-AuthSource: DB8PR04MB6795.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2021 13:55:25.5616
 (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: 9MQU0m+BFEL+KQVKpDJK7gyIsNr4s1NqBaf4zvymlX8gAztXvB250TZigpY/lykpakBJjrPbpLrA3c59VPjpjg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB4524
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Background:
We have a customer is running a Profinet stack on the 8MM which receives and
responds PNIO packets every 4ms and PNIO-CM packets every 40ms. However, from
time to time the received PNIO-CM package is "stock" and is only handled when
receiving a new PNIO-CM or DCERPC-Ping packet (tcpdump shows the PNIO-CM and
the DCERPC-Ping packet at the same time but the PNIO-CM HW timestamp is from
the expected 40 ms and not the 2s delay of the DCERPC-Ping).

After debugging, we noticed PNIO, PNIO-CM and DCERPC-Ping packets would
be handled by different RX queues.

The root cause should be driver ack all queues' interrupt when handle a
specific queue in fec_enet_rx_queue(). The blamed patch is introduced to
receive as much packets as possible once to avoid interrupt flooding.
But it's unreasonable to clear other queues'interrupt when handling one
queue, this patch tries to fix it.

Fixes: ed63f1dcd578 (net: fec: clear receive interrupts before processing a packet)
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Reported-by: Nicolas Diaz <nicolas.diaz@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
ChangeLogs:
V1->V2:
	* introduce a macro to get receive queue interrupt
	* change to formal patch
---
 drivers/net/ethernet/freescale/fec.h      | 3 +++
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 7b4961daa254..ed7301b69169 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -377,6 +377,9 @@ struct bufdesc_ex {
 #define FEC_ENET_WAKEUP	((uint)0x00020000)	/* Wakeup request */
 #define FEC_ENET_TXF	(FEC_ENET_TXF_0 | FEC_ENET_TXF_1 | FEC_ENET_TXF_2)
 #define FEC_ENET_RXF	(FEC_ENET_RXF_0 | FEC_ENET_RXF_1 | FEC_ENET_RXF_2)
+#define FEC_ENET_RXF_GET(X)	(((X) == 0) ? FEC_ENET_RXF_0 :	\
+				(((X) == 1) ? FEC_ENET_RXF_1 :	\
+				FEC_ENET_RXF_2))
 #define FEC_ENET_TS_AVAIL       ((uint)0x00010000)
 #define FEC_ENET_TS_TIMER       ((uint)0x00008000)
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index bc418b910999..1b1f7f2a6130 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1480,7 +1480,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 			break;
 		pkt_received++;
 
-		writel(FEC_ENET_RXF, fep->hwp + FEC_IEVENT);
+		writel(FEC_ENET_RXF_GET(queue_id), fep->hwp + FEC_IEVENT);
 
 		/* Check for errors. */
 		status ^= BD_ENET_RX_LAST;
-- 
2.17.1