[PATCH net v5 0/4] MAC-PHY interrupt changed to level triggered interrupt

[PATCH net v5 0/4] MAC-PHY interrupt changed to level triggered interrupt

[Selvamani Rajagopal via B4 Relay]

According to OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface
specification, MAC-PHY interrupt is "active low, level triggered".
The specification mentions about the conditions in which the IRQ
is asserted and deasserted.

Bug is inadvertently introduced by treating the IRQ in the OA TC6
framework driver and in dt-binding YAML file as edge triggered.

With the changes to use level triggered interrupt, use of threaded
irq is more efficient than the current method that has interrupt hander
working with work queue.

This change of interrupt handler mechanism exposed couple of race
conditions due to the fact that interrupts were not masked on protocol
error. And pointers were not initialized with null after skbs are freed.

Changes are done in two files
 - OA TC6 framework Ethernet driver
 - YAML file for the vendor that already uses OA TC6 framework.

Maintainer for this driver is already informed and aware of these
changes. Testing for these changes was done in onsemi's setup and
found to be working.

Changes in v5:
  - Removed the extraneous FCS that came with the frame before passing
    to the stack
  - Base commit was upadted on few patches to ensure that it is pointing
    to the correct commit ID.
  - Commit messages have been updated to be more descriptive and
    gives more detail now.
  - Couple of race conditions pointed out by AI review is fixed.

- Link to v4: https://lore.kernel.org/r/20260609-level-trigger-v4-0-6f389abdd192@onsemi.com

Changes in v4:

- IRQ handler is changed to interrupt handler + wake up thread
  to interrupt handler + threaded irq. Threaded irq mechanism
  is better suited for level triggered interrupt. Because it can
  keep the interrupt disabled until interrupting conditions are 
  handled by a handler thread.
- SPI data handling function is called again on EAGAIN error code
  as it indicates RX buffer overflow error, which requires draining
  the bad data chunks.
 
  - Changed wakeup thread to threaded IRQ 
  - RX buffer overflow is handled before threaded irq returns

- Link to v3: https://lore.kernel.org/r/20260601-level-trigger-v3-0-da73e7010532@onsemi.com

Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
---
Selvamani Rajagopal (4):
      net: ethernet: oa_tc6: Interrupt is active low, level triggered.
      net: ethernet: oa_tc6: mdiobus->parent initialized with NULL
      net: ethernet: oa_tc6: Remove FCS size in RX frame
      dt-bindings: net: updated interrupt type to be active low, level triggered

 .../devicetree/bindings/net/microchip,lan8650.yaml |   2 +-
 drivers/net/ethernet/oa_tc6.c                      | 140 +++++++++++++--------
 2 files changed, 89 insertions(+), 53 deletions(-)
---
base-commit: 22e2036479cb77df6281ebbd376ae6c330774790
change-id: 20260531-level-trigger-8cb1a83af034

Best regards,
--  
Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

[PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[Selvamani Rajagopal via B4 Relay]

From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

According OPEN Alliance 10BASET1x MAC-PHY Serial Interface
specification, interrupt is active low, level triggered.

Code used edge triggered interrupt which has the risk of losing an
interrupt on instances like when interrupt is disabled. Level
triggered interrupt won't be deasserted unless handler runs and
clear the interrupting conditions.

Interrupt handler mechanism is changed to threaded irq from
interrupt handler and kernel thread waiting on work queue.
Threaded irq mechanism is best suited for level triggered interrupt
as it disables the interrupt until handler is run in thread level,
while giving us an ability to have interrupt context handler to
signal the threaded irq handler.

Introduced a logic to disable the device interrupt on error. Error
could be due in data chunk's header and footer or SPI interface itself.
This will avoid having repeated interrupts, in case the driver couldn't
recover from the error condition with the available recovery mechanism.

Fixes: 2c6ce5354453 ("net: ethernet: oa_tc6: implement mac-phy interrupt")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

---
changes in v5:
  - Updated the commit message to be more descriptive
  - Fixed the race condition between interrupt event and threaded
    irq to avoid interrupt storm and accessing skb after freed.
changes in v4:
  Interrupt handling mechanism changed to threaded irq
changes in v3:
 interrupt registered as level triggerred
---
 drivers/net/ethernet/oa_tc6.c | 126 +++++++++++++++++++++++++-----------------
 1 file changed, 76 insertions(+), 50 deletions(-)

diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
index 91a906a7918a..f3ac2875adfb 100644
--- a/drivers/net/ethernet/oa_tc6.c
+++ b/drivers/net/ethernet/oa_tc6.c
@@ -7,6 +7,7 @@
 
 #include <linux/bitfield.h>
 #include <linux/iopoll.h>
+#include <linux/interrupt.h>
 #include <linux/mdio.h>
 #include <linux/phy.h>
 #include <linux/oa_tc6.h>
@@ -44,6 +45,8 @@
 #define INT_MASK0_LOSS_OF_FRAME_ERR_MASK	BIT(4)
 #define INT_MASK0_RX_BUFFER_OVERFLOW_ERR_MASK	BIT(3)
 #define INT_MASK0_TX_PROTOCOL_ERR_MASK		BIT(0)
+#define INT_MASK0_ALL_INTERRUPTS                (GENMASK(5, 0) | \
+						 GENMASK(12, 7))
 
 /* PHY Clause 22 registers base address and mask */
 #define OA_TC6_PHY_STD_REG_ADDR_BASE		0xFF00
@@ -121,14 +124,13 @@ struct oa_tc6 {
 	struct sk_buff *ongoing_tx_skb;
 	struct sk_buff *waiting_tx_skb;
 	struct sk_buff *rx_skb;
-	struct task_struct *spi_thread;
-	wait_queue_head_t spi_wq;
 	u16 tx_skb_offset;
 	u16 spi_data_tx_buf_offset;
 	u16 tx_credits;
 	u8 rx_chunks_available;
 	bool rx_buf_overflow;
 	bool int_flag;
+	bool disable_traffic;
 };
 
 enum oa_tc6_header_type {
@@ -669,6 +671,38 @@ static void oa_tc6_cleanup_ongoing_tx_skb(struct oa_tc6 *tc6)
 	}
 }
 
+static void oa_tc6_cleanup_waiting_tx_skb(struct oa_tc6 *tc6)
+{
+	if (tc6->waiting_tx_skb) {
+		tc6->netdev->stats.tx_dropped++;
+		kfree_skb(tc6->waiting_tx_skb);
+		tc6->waiting_tx_skb = NULL;
+	}
+}
+
+static void oa_tc6_free_pending_skbs(struct oa_tc6 *tc6)
+{
+	oa_tc6_cleanup_ongoing_tx_skb(tc6);
+	oa_tc6_cleanup_ongoing_rx_skb(tc6);
+	oa_tc6_cleanup_waiting_tx_skb(tc6);
+}
+
+/* If the failure is at SPI interface level, masking and clearing
+ * the interrupt of the device won't work. Since SPI interrupt is
+ * disabled, it should stop the repeated interrupts.
+ */
+static void oa_tc6_disable_traffic(struct oa_tc6 *tc6)
+{
+	u32 regval = INT_MASK0_ALL_INTERRUPTS;
+
+	tc6->disable_traffic = true;
+	oa_tc6_free_pending_skbs(tc6);
+	oa_tc6_write_register(tc6, OA_TC6_REG_INT_MASK0, regval);
+	oa_tc6_read_register(tc6, OA_TC6_REG_STATUS0, &regval);
+	oa_tc6_write_register(tc6, OA_TC6_REG_STATUS0, regval);
+	dev_err(&tc6->spi->dev, "Device interrupt disabled to avoid interrupt storm");
+}
+
 static int oa_tc6_process_extended_status(struct oa_tc6 *tc6)
 {
 	u32 value;
@@ -1105,29 +1139,29 @@ static int oa_tc6_try_spi_transfer(struct oa_tc6 *tc6)
 	return 0;
 }
 
-static int oa_tc6_spi_thread_handler(void *data)
+static irqreturn_t oa_tc6_macphy_threaded_irq(int irq, void *data)
 {
 	struct oa_tc6 *tc6 = data;
-	int ret;
-
-	while (likely(!kthread_should_stop())) {
-		/* This kthread will be waken up if there is a tx skb or mac-phy
-		 * interrupt to perform spi transfer with tx chunks.
-		 */
-		wait_event_interruptible(tc6->spi_wq, tc6->int_flag ||
-					 (tc6->waiting_tx_skb &&
-					 tc6->tx_credits) ||
-					 kthread_should_stop());
-
-		if (kthread_should_stop())
-			break;
+	int ret = 0;
 
-		ret = oa_tc6_try_spi_transfer(tc6);
-		if (ret)
-			return ret;
+	/* It is possible that interrupt woke the thread before it is
+	 * disabled. Until we come up with good recovery mechanism,
+	 * no need to attempt spi transfer, once it fails. Pending skbs
+	 * are already freed.
+	 */
+	if (!tc6->disable_traffic) {
+		while (tc6->int_flag ||
+		       (tc6->waiting_tx_skb && tc6->tx_credits)) {
+			ret = oa_tc6_try_spi_transfer(tc6);
+			if (ret) {
+				disable_irq_nosync(tc6->spi->irq);
+				oa_tc6_disable_traffic(tc6);
+				break;
+			}
+		}
 	}
 
-	return 0;
+	return IRQ_HANDLED;
 }
 
 static int oa_tc6_update_buffer_status_from_register(struct oa_tc6 *tc6)
@@ -1161,11 +1195,15 @@ static irqreturn_t oa_tc6_macphy_isr(int irq, void *data)
 	 *   the previous rx footer.
 	 * - extended status event not reported in the previous rx footer.
 	 */
-	tc6->int_flag = true;
-	/* Wake spi kthread to perform spi transfer */
-	wake_up_interruptible(&tc6->spi_wq);
-
-	return IRQ_HANDLED;
+	if (tc6->disable_traffic)
+		disable_irq_nosync(tc6->spi->irq);
+	else
+		tc6->int_flag = true;
+	/* Wake IRQ thread to perform spi transfer . In case
+	 * disable_traffic is set, threaded irq may run again
+	 * one more time.
+	 */
+	return IRQ_WAKE_THREAD;
 }
 
 /**
@@ -1202,7 +1240,7 @@ EXPORT_SYMBOL_GPL(oa_tc6_zero_align_receive_frame_enable);
  */
 netdev_tx_t oa_tc6_start_xmit(struct oa_tc6 *tc6, struct sk_buff *skb)
 {
-	if (tc6->waiting_tx_skb) {
+	if (tc6->disable_traffic || tc6->waiting_tx_skb) {
 		netif_stop_queue(tc6->netdev);
 		return NETDEV_TX_BUSY;
 	}
@@ -1217,8 +1255,8 @@ netdev_tx_t oa_tc6_start_xmit(struct oa_tc6 *tc6, struct sk_buff *skb)
 	tc6->waiting_tx_skb = skb;
 	spin_unlock_bh(&tc6->tx_skb_lock);
 
-	/* Wake spi kthread to perform spi transfer */
-	wake_up_interruptible(&tc6->spi_wq);
+	/* Wake the threaded IRQ to perform spi transfer. */
+	irq_wake_thread(tc6->spi->irq, tc6);
 
 	return NETDEV_TX_OK;
 }
@@ -1311,24 +1349,15 @@ struct oa_tc6 *oa_tc6_init(struct spi_device *spi, struct net_device *netdev)
 		goto phy_exit;
 	}
 
-	init_waitqueue_head(&tc6->spi_wq);
-
-	tc6->spi_thread = kthread_run(oa_tc6_spi_thread_handler, tc6,
-				      "oa-tc6-spi-thread");
-	if (IS_ERR(tc6->spi_thread)) {
-		dev_err(&tc6->spi->dev, "Failed to create SPI thread\n");
-		goto phy_exit;
-	}
-
-	sched_set_fifo(tc6->spi_thread);
-
-	ret = devm_request_irq(&tc6->spi->dev, tc6->spi->irq, oa_tc6_macphy_isr,
-			       IRQF_TRIGGER_FALLING, dev_name(&tc6->spi->dev),
-			       tc6);
+	ret = devm_request_threaded_irq(&tc6->spi->dev, tc6->spi->irq,
+					oa_tc6_macphy_isr,
+					oa_tc6_macphy_threaded_irq,
+					IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+					dev_name(&tc6->spi->dev), tc6);
 	if (ret) {
 		dev_err(&tc6->spi->dev, "Failed to request macphy isr %d\n",
 			ret);
-		goto kthread_stop;
+		goto phy_exit;
 	}
 
 	/* oa_tc6_sw_reset_macphy() function resets and clears the MAC-PHY reset
@@ -1338,12 +1367,10 @@ struct oa_tc6 *oa_tc6_init(struct spi_device *spi, struct net_device *netdev)
 	 * 7.7 and 9.2.8.8 in the OPEN Alliance specification for more details.
 	 */
 	tc6->int_flag = true;
-	wake_up_interruptible(&tc6->spi_wq);
+	irq_wake_thread(tc6->spi->irq, tc6);
 
 	return tc6;
 
-kthread_stop:
-	kthread_stop(tc6->spi_thread);
 phy_exit:
 	oa_tc6_phy_exit(tc6);
 	return NULL;
@@ -1356,11 +1383,10 @@ EXPORT_SYMBOL_GPL(oa_tc6_init);
  */
 void oa_tc6_exit(struct oa_tc6 *tc6)
 {
+	tc6->disable_traffic = true;
+	disable_irq(tc6->spi->irq);
 	oa_tc6_phy_exit(tc6);
-	kthread_stop(tc6->spi_thread);
-	dev_kfree_skb_any(tc6->ongoing_tx_skb);
-	dev_kfree_skb_any(tc6->waiting_tx_skb);
-	dev_kfree_skb_any(tc6->rx_skb);
+	oa_tc6_free_pending_skbs(tc6);
 }
 EXPORT_SYMBOL_GPL(oa_tc6_exit);
 

-- 
2.43.0

[PATCH net v5 2/4] net: ethernet: oa_tc6: mdiobus->parent initialized with NULL

[Selvamani Rajagopal via B4 Relay]

From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

As "dev" pointer in oa_tc6 structure is never initialized,
mbiobus->parent was initialized with NULL.  This change
fixes it by initializing it with device pointer of spi.

Fixes: 8f9bf857e43b ("net: ethernet: oa_tc6: implement internal PHY initialization")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

---
changes in v5:
  Changed Fixes: commit ID to accurately reflect where issue originated
changes in v4:
   new patch
---
 drivers/net/ethernet/oa_tc6.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
index f3ac2875adfb..477ceefde2c5 100644
--- a/drivers/net/ethernet/oa_tc6.c
+++ b/drivers/net/ethernet/oa_tc6.c
@@ -110,7 +110,6 @@
 
 /* Internal structure for MAC-PHY drivers */
 struct oa_tc6 {
-	struct device *dev;
 	struct net_device *netdev;
 	struct phy_device *phydev;
 	struct mii_bus *mdiobus;
@@ -520,7 +519,7 @@ static int oa_tc6_mdiobus_register(struct oa_tc6 *tc6)
 	tc6->mdiobus->read_c45 = oa_tc6_mdiobus_read_c45;
 	tc6->mdiobus->write_c45 = oa_tc6_mdiobus_write_c45;
 	tc6->mdiobus->name = "oa-tc6-mdiobus";
-	tc6->mdiobus->parent = tc6->dev;
+	tc6->mdiobus->parent = &tc6->spi->dev;
 
 	snprintf(tc6->mdiobus->id, ARRAY_SIZE(tc6->mdiobus->id), "%s",
 		 dev_name(&tc6->spi->dev));

-- 
2.43.0

[PATCH net v5 3/4] net: ethernet: oa_tc6: Remove FCS size in RX frame

[Selvamani Rajagopal via B4 Relay]

From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

OA TC6 MAC-PHY appends FCS to the incoming frame. It must be
removed from the frame before being passed to the stack.

With FCS in the frame, many applications, like ping or any
application that uses IP layer may work as they may
carry the packet size information in the protocol.

Application like ptp4l, particularly if it uses layer 2
for its communication, it will fail with "bad message" due to
the extra 4 bytes added by the presence of FCS.

Fixes: d70a0d8f2f2d ("net: ethernet: oa_tc6: implement receive path to receive rx ethernet frames")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

---
changes in v5
  - Removed FCS present at the end of the MAC frame before being
    passed to the stack.
  - new patch
---
 drivers/net/ethernet/oa_tc6.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
index 477ceefde2c5..0727d53345a3 100644
--- a/drivers/net/ethernet/oa_tc6.c
+++ b/drivers/net/ethernet/oa_tc6.c
@@ -785,6 +785,17 @@ static int oa_tc6_process_rx_chunk_footer(struct oa_tc6 *tc6, u32 footer)
 
 static void oa_tc6_submit_rx_skb(struct oa_tc6 *tc6)
 {
+	/* MAC-PHY delivers each frame with its Ethernet FCS attached.
+	 * Strip it before handing over to the stack, unless the user
+	 * has asked to keep it via NETIF_F_RXFCS. Keeping the FCS
+	 * in the frame is harmless for IP traffic, but is parsed as
+	 * a (malformed) suffix TLV by PTP, which makes ptp4l reject
+	 * every message with "bad message" error.
+	 */
+	if (!(tc6->netdev->features & NETIF_F_RXFCS) &&
+	    tc6->rx_skb->len > ETH_FCS_LEN)
+		skb_trim(tc6->rx_skb, tc6->rx_skb->len - ETH_FCS_LEN);
+
 	tc6->rx_skb->protocol = eth_type_trans(tc6->rx_skb, tc6->netdev);
 	tc6->netdev->stats.rx_packets++;
 	tc6->netdev->stats.rx_bytes += tc6->rx_skb->len;

-- 
2.43.0

[PATCH net v5 4/4] dt-bindings: net: updated interrupt type to be active low, level triggered

[Selvamani Rajagopal via B4 Relay]

From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
specification, interrupt type is active low, level triggered interrupt.

Specification calls for when interrupt level will be asserted and what
condition it is de-asserted. By using edge triggered interrupt, there is a
potential chance to miss it, particularly if it is asserted when interrupt
is disabled.

Level triggered interrupt can't be missed as it gets de-asserted only on
interrupt handler taking actions on interrupting conditions.

Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

---
changes in v5
  Added better, descriptive commit message
changes in v4
  no change
changes in v3
  interrupts entry changed to level triggered from edge triggered
---
 Documentation/devicetree/bindings/net/microchip,lan8650.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
index 61e11d4a07c4..766ff58147ae 100644
--- a/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
+++ b/Documentation/devicetree/bindings/net/microchip,lan8650.yaml
@@ -67,7 +67,7 @@ examples:
         pinctrl-names = "default";
         pinctrl-0 = <&eth0_pins>;
         interrupt-parent = <&gpio>;
-        interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+        interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
         local-mac-address = [04 05 06 01 02 03];
         spi-max-frequency = <15000000>;
       };

-- 
2.43.0

Re: [PATCH net v5 4/4] dt-bindings: net: updated interrupt type to be active low, level triggered

[Krzysztof Kozlowski]

On Thu, Jun 11, 2026 at 02:55:41PM -0700, Selvamani Rajagopal wrote:
> According to OPEN Alliance 10BASE-T1x MACPHY Serial Interface (TC6)
> specification, interrupt type is active low, level triggered interrupt.
> 
> Specification calls for when interrupt level will be asserted and what
> condition it is de-asserted. By using edge triggered interrupt, there is a
> potential chance to miss it, particularly if it is asserted when interrupt
> is disabled.
> 
> Level triggered interrupt can't be missed as it gets de-asserted only on
> interrupt handler taking actions on interrupting conditions.
> 
> Fixes: ac49b950bea9 ("dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY")
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> 

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH net v5 0/4] MAC-PHY interrupt changed to level triggered interrupt

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 11 Jun 2026 14:55:37 -0700 you wrote:
> According to OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface
> specification, MAC-PHY interrupt is "active low, level triggered".
> The specification mentions about the conditions in which the IRQ
> is asserted and deasserted.
> 
> Bug is inadvertently introduced by treating the IRQ in the OA TC6
> framework driver and in dt-binding YAML file as edge triggered.
> 
> [...]

Here is the summary with links:
  - [net,v5,1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.
    https://git.kernel.org/netdev/net/c/b542d13fab0f
  - [net,v5,2/4] net: ethernet: oa_tc6: mdiobus->parent initialized with NULL
    https://git.kernel.org/netdev/net/c/a221d3f7e3f3
  - [net,v5,3/4] net: ethernet: oa_tc6: Remove FCS size in RX frame
    https://git.kernel.org/netdev/net/c/a5a1d11dd372
  - [net,v5,4/4] dt-bindings: net: updated interrupt type to be active low, level triggered
    https://git.kernel.org/netdev/net/c/31e56112e654

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[Parthiban.Veerasooran]

Hi Selvamani,

I did a quick test by connecting Mikroe LAN8651 Click to a Raspberry Pi 
4 and shared the feedback below. Please let me know if you need any 
further details.

Test case 1: Single LAN8651 instance on RPI4

Setup:

RPI4 #1 + LAN8651 (IP: 192.168.10.101) <--- RPI4 #2 + EVB-LAN8670-USB 
(IP: 192.168.10.102)

Commands:

iperf3 -s -p 5001 <--- iperf3 -c 192.168.10.101 -u -b 9.4M -i 1 -t 0 -p 5001

Result:

No issues observed.

Test case 2: Two LAN8651 instances on the same RPI4

Setup:

RPI4 #1 + LAN8651 (IP: 192.168.10.101) <--- RPI4 #2 + EVB-LAN8670-USB 
(IP: 192.168.10.102)
RPI4 #1 + LAN8651 (IP: 192.168.20.101) <--- RPI4 #2 + EVB-LAN8670-USB 
(IP: 192.168.20.102)

Result:

Initially working fine with continuous "Receive buffer overflow" errors. 
This is expected, as both USB devices transmit at full speed while RPI4 
can handle the traffic only up to a maximum SPI frequency of 15 MHz. 
Eventually, the system crashed. The crash message was captured in the 
dmesg log,

[ 8276.676335] net_ratelimit: 2448 callbacks suppressed
[ 8276.676341] eth1: Receive buffer overflow error
[ 8276.676349] eth2: Receive buffer overflow error
[ 8276.680025] eth2: Receive buffer overflow error
[ 8276.680033] eth1: Receive buffer overflow error
[ 8276.683701] eth2: Receive buffer overflow error
[ 8276.683710] eth1: Receive buffer overflow error
[ 8276.687378] eth2: Receive buffer overflow error
[ 8276.687387] eth1: Receive buffer overflow error
[ 8276.691055] eth2: Receive buffer overflow error
[ 8276.691064] eth1: Receive buffer overflow error
[ 8281.662600] Unable to handle kernel NULL pointer dereference at 
virtual address 0000000000000074
[ 8281.670936] Mem abort info:
[ 8281.673747]   ESR = 0x0000000096000005
[ 8281.677544]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 8281.682917]   SET = 0, FnV = 0
[ 8281.685997]   EA = 0, S1PTW = 0
[ 8281.689173]   FSC = 0x05: level 1 translation fault
[ 8281.694109] Data abort info:
[ 8281.697017]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 8281.702571]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 8281.707680]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 8281.713056] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000040a1d000
[ 8281.719578] [0000000000000074] pgd=0000000000000000, 
p4d=0000000000000000, pud=0000000000000000
[ 8281.728391] Internal error: Oops: 0000000096000005 [#1]  SMP
[ 8281.734115] Modules linked in: sch_fq lan865x_t1s(O) microchip_t1s(O) 
snd_seq_dummy snd_hrtimer snd_seq snd_seq_device rfcomm algif_hash 
aes_neon_bs algif_skcipher af_alg bnep binfmt_misc brcmfmac_cyw brcmfmac 
vc4 hci_uart brcmutil btbcm bluetooth v3d snd_soc_hdmi_codec bcm2835_isp 
cfg80211 rpi_hevc_dec bcm2835_codec(C) drm_exec bcm2835_v4l2(C) 
drm_display_helper ecdh_generic cec ecc bcm2835_mmal_vchiq gpu_sched 
videobuf2_vmalloc vc_sm_cma v4l2_mem2mem drm_dma_helper rfkill crc_ccitt 
drm_client_lib drm_shmem_helper videobuf2_dma_contig videobuf2_memops 
drm_kms_helper videobuf2_v4l2 snd_soc_core videodev raspberrypi_hwmon 
snd_bcm2835(C) snd_compress i2c_brcmstb snd_pcm_dmaengine snd_pcm 
videobuf2_common snd_timer mc raspberrypi_gpiomem spi_bcm2835 snd 
gpio_fan nvmem_rmem sch_fq_codel i2c_dev zram lz4_compress drm fuse 
drm_panel_orientation_quirks backlight nfnetlink
[ 8281.811847] CPU: 3 UID: 0 PID: 1759 Comm: irq/59-spi0.0 Tainted: G 
      C O        7.1.0-rc7-v8+ #1 PREEMPT
[ 8281.822067] Tainted: [C]=CRAP, [O]=OOT_MODULE
[ 8281.826473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 8281.832377] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)
[ 8281.839427] pc : skb_put+0x14/0x80
[ 8281.842864] lr : oa_tc6_macphy_threaded_irq+0x428/0x880 [lan865x_t1s]
[ 8281.849386] sp : ffffffc083c4bd40
[ 8281.852735] x29: ffffffc083c4bd40 x28: 000000002020003e x27: 
ffffffe59e5609c8
[ 8281.859962] x26: ffffff8103d55080 x25: 0000000000000001 x24: 
ffffff8040566880
[ 8281.867187] x23: 0000000000000001 x22: 0000000000000000 x21: 
0000000000000000
[ 8281.874414] x20: 000000003e002020 x19: ffffff80405668a0 x18: 
00000000000b6748
[ 8281.881641] x17: ffffff9b64502000 x16: ffffffe59f08cef0 x15: 
1ae8add2c0a08935
[ 8281.888867] x14: b154d86008ee08e7 x13: b66a1ae8add2c0a0 x12: 
8935b154d86008ee
[ 8281.896093] x11: 00000000000000c0 x10: 0000000000001ae0 x9 : 
ffffffe590bb7918
[ 8281.903320] x8 : ffffff80493c1b40 x7 : 0000000000000004 x6 : 
ffffffffffffffff
[ 8281.910547] x5 : ffffffe59fb9d000 x4 : 0000000000000004 x3 : 
0000000000000000
[ 8281.917773] x2 : 0000000000000000 x1 : 0000000000000040 x0 : 
0000000000000000
[ 8281.925000] Call trace:
[ 8281.927468]  skb_put+0x14/0x80 (P)
[ 8281.930905]  oa_tc6_macphy_threaded_irq+0x428/0x880 [lan865x_t1s]
[ 8281.937073]  irq_thread_fn+0x34/0xc0
[ 8281.940686]  irq_thread+0x1a8/0x308
[ 8281.944212]  kthread+0x138/0x150
[ 8281.947472]  ret_from_fork+0x10/0x20
[ 8281.951089] Code: d503201f d503233f a9bf7bfd 910003fd (b9407406)
[ 8281.957258] ---[ end trace 0000000000000000 ]---
[ 8281.961969] genirq: exiting task "irq/59-spi0.0" (1759) is an active 
IRQ thread (irq 59)
[ 8282.080140] irq 59: nobody cared (try booting with the "irqpoll" option)
[ 8282.086344] CPU: 0 UID: 0 PID: 15 Comm: rcu_preempt Tainted: G      D 
  C O        7.1.0-rc7-v8+ #1 PREEMPT
[ 8282.086352] Tainted: [D]=DIE, [C]=CRAP, [O]=OOT_MODULE
[ 8282.086354] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 8282.086357] Call trace:
[ 8282.086359]  show_stack+0x20/0x38 (C)
[ 8282.086372]  dump_stack_lvl+0x60/0x80
[ 8282.086378]  dump_stack+0x18/0x24
[ 8282.086382]  __report_bad_irq+0x54/0xf0
[ 8282.086388]  note_interrupt+0x344/0x398
[ 8282.086393]  handle_irq_event+0xa4/0x110
[ 8282.086397]  handle_level_irq+0xe0/0x178
[ 8282.086401]  handle_irq_desc+0x3c/0x68
[ 8282.086407]  generic_handle_domain_irq+0x20/0x40
[ 8282.086413]  bcm2835_gpio_irq_handle_bank+0x180/0x1c8
[ 8282.086420]  bcm2835_gpio_irq_handler+0x88/0x188
[ 8282.086424]  handle_irq_desc+0x3c/0x68
[ 8282.086430]  generic_handle_domain_irq+0x20/0x40
[ 8282.086435]  gic_handle_irq+0x4c/0xe0
[ 8282.086438]  call_on_irq_stack+0x30/0x88
[ 8282.086444]  do_interrupt_handler+0x88/0x98
[ 8282.086447]  el1_interrupt+0x3c/0x60
[ 8282.086452]  el1h_64_irq_handler+0x18/0x30
[ 8282.086457]  el1h_64_irq+0x6c/0x70
[ 8282.086460]  _raw_spin_unlock_irq+0x10/0x60 (P)
[ 8282.086465]  rcu_gp_kthread+0x2f0/0x310
[ 8282.086471]  kthread+0x138/0x150
[ 8282.086476]  ret_from_fork+0x10/0x20
[ 8282.086481] handlers:
[ 8282.170193] lan8650 spi0.1: SPI transfer timed out
[ 8282.170591] [<0000000094f492f8>] oa_tc6_macphy_isr [lan865x_t1s]
[ 8282.174845] spi_master spi0: failed to transfer one message from queue
[ 8282.178435]  threaded [<000000008b769ba3>] oa_tc6_macphy_threaded_irq 
[lan865x_t1s]
[ 8282.178443] spi_master spi0: noqueue transfer failed

[ 8282.182578] Disabling IRQ #59
[ 8282.238458] lan8650 spi0.1 eth2: SPI data transfer failed: -110
[ 8282.244490] lan8650 spi0.1: Device interrupt disabled to avoid 
interrupt storm

Best regards,
Parthiban V

On 12/06/26 3:25 am, Selvamani Rajagopal via B4 Relay wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> 
> According OPEN Alliance 10BASET1x MAC-PHY Serial Interface
> specification, interrupt is active low, level triggered.
> 
> Code used edge triggered interrupt which has the risk of losing an
> interrupt on instances like when interrupt is disabled. Level
> triggered interrupt won't be deasserted unless handler runs and
> clear the interrupting conditions.
> 
> Interrupt handler mechanism is changed to threaded irq from
> interrupt handler and kernel thread waiting on work queue.
> Threaded irq mechanism is best suited for level triggered interrupt
> as it disables the interrupt until handler is run in thread level,
> while giving us an ability to have interrupt context handler to
> signal the threaded irq handler.
> 
> Introduced a logic to disable the device interrupt on error. Error
> could be due in data chunk's header and footer or SPI interface itself.
> This will avoid having repeated interrupts, in case the driver couldn't
> recover from the error condition with the available recovery mechanism.
> 
> Fixes: 2c6ce5354453 ("net: ethernet: oa_tc6: implement mac-phy interrupt")
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>

RE: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[Selvamani Rajagopal]

> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
> triggered.
> 
> 
> Hi Selvamani,
> 
> I did a quick test by connecting Mikroe LAN8651 Click to a Raspberry Pi
> 4 and shared the feedback below. Please let me know if you need any
> further details.

Parthiban,

Thanks for testing this.

Though the NULL pointer reference after skb_put is a clue, I am working with our team to see we can see this crash in our setup.
Will keep you updated.

> 
> [ 8276.691064] eth1: Receive buffer overflow error
> [ 8281.662600] Unable to handle kernel NULL pointer dereference at
> virtual address 0000000000000074> drm_panel_orientation_quirks backlight nfnetlink
> [ 8281.839427] pc : skb_put+0x14/0x80
> [ 8281.842864] lr : oa_tc6_macphy_threaded_irq+0x428/0x880 [lan865x_t1s]

Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[Parthiban.Veerasooran]

Hi Selvamani,

On 17/06/26 10:24 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
>> triggered.
>>
>>
>> Hi Selvamani,
>>
>> I did a quick test by connecting Mikroe LAN8651 Click to a Raspberry Pi
>> 4 and shared the feedback below. Please let me know if you need any
>> further details.
> 
> Parthiban,
> 
> Thanks for testing this.
> 
> Though the NULL pointer reference after skb_put is a clue, I am working with our team to see we can see this crash in our setup.
> Will keep you updated.
Sure, thank you.

Best regards,
Parthiban V
> 
>>
>> [ 8276.691064] eth1: Receive buffer overflow error
>> [ 8281.662600] Unable to handle kernel NULL pointer dereference at
>> virtual address 0000000000000074> drm_panel_orientation_quirks backlight nfnetlink
>> [ 8281.839427] pc : skb_put+0x14/0x80
>> [ 8281.842864] lr : oa_tc6_macphy_threaded_irq+0x428/0x880 [lan865x_t1s]
> 

RE: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.

[Selvamani Rajagopal]

> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
> triggered.
> 
> 
> 
> Test case 2: Two LAN8651 instances on the same RPI4
> 
> Setup:
> 
> RPI4 #1 + LAN8651 (IP: 192.168.10.101) <--- RPI4 #2 + EVB-LAN8670-USB
> (IP: 192.168.10.102)
> RPI4 #1 + LAN8651 (IP: 192.168.20.101) <--- RPI4 #2 + EVB-LAN8670-USB
> (IP: 192.168.20.102)
> 
> Result:
> 

Parthiban,

It appears that we can't reproduce the crash you saw in your setup. Code has been running
all day with 5+ millions of "™Receive buffer overflow error" (Yes. I added a counter to see how 
many times, code returns EAGAIN error code)

One obvious reason is that our EVB has only one network interface. Just like your setup in Test case 1,
where you didn't see any issue.

AI review bot Sashiko suggested one potential issue where skb pointers aren't protected. But those 
concerns are in transmit path. This crash seems to be in receive path. If you think that might help,
I can generate a patch for that.

What do you suggest? Since you are able to see the crash, would you have time to investigate?

Sincerely
Selva