This is a note to let you know that I've just added the patch titled net: enetc: remove bogus write to SIRXIDR from enetc_setup_rxbdr to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: net-enetc-remove-bogus-write-to-sirxidr-from-enetc_setup_rxbdr.patch and it can be found in the queue-5.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@xxxxxxxxxxxxxxx> know about it. >From 96a5223b918c8b79270fc0fec235a7ebad459098 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean <vladimir.oltean@xxxxxxx> Date: Mon, 1 Mar 2021 13:18:17 +0200 Subject: net: enetc: remove bogus write to SIRXIDR from enetc_setup_rxbdr From: Vladimir Oltean <vladimir.oltean@xxxxxxx> commit 96a5223b918c8b79270fc0fec235a7ebad459098 upstream. The Station Interface Receive Interrupt Detect Register (SIRXIDR) contains a 16-bit wide mask of 'interrupt detected' events for each ring associated with a port. Bit i is write-1-to-clean for RX ring i. I have no explanation whatsoever how this line of code came to be inserted in the blamed commit. I checked the downstream versions of that patch and none of them have it. The somewhat comical aspect of it is that we're writing a binary number to the SIRXIDR register, which is derived from enetc_bd_unused(rx_ring). Since the RX rings have 512 buffer descriptors, we end up writing 511 to this register, which is 0x1ff, so we are effectively clearing the 'interrupt detected' event for rings 0-8. This register is not what is used for interrupt handling though - it only provides a summary for the entire SI. The hardware provides one separate Interrupt Detect Register per RX ring, which auto-clears upon read. So there doesn't seem to be any adverse effect caused by this bogus write. There is, however, one reason why this should be handled as a bugfix: next_to_clean _should_ be committed to hardware, just not to that register, and this was obscuring the fact that it wasn't. This is fixed in the next patch, and removing the bogus line now allows the fix patch to be backported beyond that point. Fixes: fd5736bf9f23 ("enetc: Workaround for MDIO register access issue") Signed-off-by: Vladimir Oltean <vladimir.oltean@xxxxxxx> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- drivers/net/ethernet/freescale/enetc/enetc.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/net/ethernet/freescale/enetc/enetc.c +++ b/drivers/net/ethernet/freescale/enetc/enetc.c @@ -1252,7 +1252,6 @@ static void enetc_setup_rxbdr(struct ene rx_ring->idr = hw->reg + ENETC_SIRXIDR; enetc_refill_rx_ring(rx_ring, enetc_bd_unused(rx_ring)); - enetc_wr(hw, ENETC_SIRXIDR, rx_ring->next_to_use); /* enable ring */ enetc_rxbdr_wr(hw, idx, ENETC_RBMR, rbmr); Patches currently in stable-queue which might be from vladimir.oltean@xxxxxxx are queue-5.10/net-enetc-fix-incorrect-tpid-when-receiving-802.1ad-tagged-packets.patch queue-5.10/net-enetc-don-t-overwrite-the-rss-indirection-table-when-initializing.patch queue-5.10/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch queue-5.10/net-enetc-remove-bogus-write-to-sirxidr-from-enetc_setup_rxbdr.patch queue-5.10/net-enetc-take-the-mdio-lock-only-once-per-napi-poll-cycle.patch queue-5.10/net-enetc-don-t-disable-vlan-filtering-in-iff_promisc-mode.patch queue-5.10/net-enetc-force-the-rgmii-speed-and-duplex-instead-of-operating-in-inband-mode.patch