kernel/drivers/net/ethernet/cadence/macb_main.c, branch linux-rolling-stable

net: macb: Shuffle the tx ring before enabling tx

2026-03-19T15:15:23Z

commit 881a0263d502e1a93ebc13a78254e9ad19520232 upstream. Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board, the rootfs may take an extended time to recover after a suspend. Upon investigation, it was determined that the issue originates from a problem in the macb driver. According to the Zynq UltraScale TRM [1], when transmit is disabled, the transmit buffer queue pointer resets to point to the address specified by the transmit buffer queue base address register. In the current implementation, the code merely resets `queue->tx_head` and `queue->tx_tail` to '0'. This approach presents several issues: - Packets already queued in the tx ring are silently lost, leading to memory leaks since the associated skbs cannot be released. - Concurrent write access to `queue->tx_head` and `queue->tx_tail` may occur from `macb_tx_poll()` or `macb_start_xmit()` when these values are reset to '0'. - The transmission may become stuck on a packet that has already been sent out, with its 'TX_USED' bit set, but has not yet been processed. However, due to the manipulation of 'queue->tx_head' and 'queue->tx_tail', `macb_tx_poll()` incorrectly assumes there are no packets to handle because `queue->tx_head == queue->tx_tail`. This issue is only resolved when a new packet is placed at this position. This is the root cause of the prolonged recovery time observed for the NFS root filesystem. To resolve this issue, shuffle the tx ring and tx skb array so that the first unsent packet is positioned at the start of the tx ring. Additionally, ensure that updates to `queue->tx_head` and `queue->tx_tail` are properly protected with the appropriate lock. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: bf9cf80cab81 ("net: macb: Fix tx/rx malfunction after phy link down and up") Reported-by: Quanyang Wang Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260307-zynqmp-v2-1-6ef98a70e1d0@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net: macb: Fix tx/rx malfunction after phy link down and up

2026-03-04T12:21:39Z

[ Upstream commit bf9cf80cab81e39701861a42877a28295ade266f ] In commit 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()"), the mog_init_rings() callback was moved from macb_mac_link_up() to macb_open() to resolve a deadlock issue. However, this change introduced a tx/rx malfunction following phy link down and up events. The issue arises from a mismatch between the software queue->tx_head, queue->tx_tail, queue->rx_prepared_head, and queue->rx_tail values and the hardware's internal tx/rx queue pointers. According to the Zynq UltraScale TRM [1], when tx/rx is disabled, the internal tx queue pointer resets to the value in the tx queue base address register, while the internal rx queue pointer remains unchanged. The following is quoted from the Zynq UltraScale TRM: When transmit is disabled, with bit [3] of the network control register set low, the transmit-buffer queue pointer resets to point to the address indicated by the transmit-buffer queue base address register. Disabling receive does not have the same effect on the receive-buffer queue pointer. Additionally, there is no need to reset the RBQP and TBQP registers in a phy event callback. Therefore, move macb_init_buffers() to macb_open(). In a phy link up event, the only required action is to reset the tx software head and tail pointers to align with the hardware's behavior. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm Fixes: 99537d5c476c ("net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()") Signed-off-by: Kevin Hao Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260208-macb-init-ring-v1-1-939a32c14635@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()

2025-12-30T10:27:45Z

In the non-RT kernel, local_bh_disable() merely disables preemption, whereas it maps to an actual spin lock in the RT kernel. Consequently, when attempting to refill RX buffers via netdev_alloc_skb() in macb_mac_link_up(), a deadlock scenario arises as follows: WARNING: possible circular locking dependency detected 6.18.0-08691-g2061f18ad76e #39 Not tainted ------------------------------------------------------ kworker/0:0/8 is trying to acquire lock: ffff00080369bbe0 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x808/0xb7c but task is already holding lock: ffff000803698e58 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit +0x148/0xb7c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&queue->tx_ptr_lock){+...}-{3:3}: rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x148/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #2 (_xmit_ETHER#2){+...}-{3:3}: rt_spin_lock+0x50/0x1f0 sch_direct_xmit+0x11c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}: lock_release+0x250/0x348 __local_bh_enable_ip+0x7c/0x240 __netdev_alloc_skb+0x1b4/0x1d8 gem_rx_refill+0xdc/0x240 gem_init_rings+0xb4/0x108 macb_mac_link_up+0x9c/0x2b4 phylink_resolve+0x170/0x614 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 -> #0 (&bp->lock){+.+.}-{3:3}: __lock_acquire+0x15a8/0x2084 lock_acquire+0x1cc/0x350 rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x808/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 other info that might help us debug this: Chain exists of: &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&queue->tx_ptr_lock); lock(_xmit_ETHER#2); lock(&queue->tx_ptr_lock); lock(&bp->lock); *** DEADLOCK *** Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0xa0/0xf0 dump_stack+0x18/0x24 print_circular_bug+0x28c/0x370 check_noncircular+0x198/0x1ac __lock_acquire+0x15a8/0x2084 lock_acquire+0x1cc/0x350 rt_spin_lock+0x50/0x1f0 macb_start_xmit+0x808/0xb7c dev_hard_start_xmit+0x94/0x284 sch_direct_xmit+0x8c/0x37c __dev_queue_xmit+0x708/0x1120 neigh_resolve_output+0x148/0x28c ip6_finish_output2+0x2c0/0xb2c __ip6_finish_output+0x114/0x308 ip6_output+0xc4/0x4a4 mld_sendpack+0x220/0x68c mld_ifc_work+0x2a8/0x4f4 process_one_work+0x20c/0x5f8 worker_thread+0x1b0/0x35c kthread+0x144/0x200 ret_from_fork+0x10/0x20 Notably, invoking the mog_init_rings() callback upon link establishment is unnecessary. Instead, we can exclusively call mog_init_rings() within the ndo_open() callback. This adjustment resolves the deadlock issue. Furthermore, since MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings() when opening the network interface via at91ether_open(), moving mog_init_rings() to macb_open() also eliminates the MACB_CAPS_MACB_IS_EMAC check. Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()") Cc: stable@vger.kernel.org Suggested-by: Kevin Hao Signed-off-by: Xiaolei Wang Link: https://patch.msgid.link/20251222015624.1994551-1-xiaolei.wang@windriver.com Signed-off-by: Paolo Abeni

net: ethernet: Remove redundant pm_runtime_mark_last_busy() calls

2025-10-30T01:55:50Z

pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus Reviewed-by: Niklas Söderlund Link: https://patch.msgid.link/20251027115022.390997-1-sakari.ailus@linux.intel.com Signed-off-by: Jakub Kicinski

net: macb: Add "mobileye,eyeq5-gem" compatible

2025-10-28T14:17:54Z

Add support for the two GEM instances inside Mobileye EyeQ5 SoCs, using compatible "mobileye,eyeq5-gem". With it, add a custom init sequence that must grab a generic PHY and initialise it. We use bp->phy in both RGMII and SGMII cases. Tell our mode by adding a phy_set_mode_ext() during macb_open(), before phy_power_on(). We are the first users of bp->phy that use it in non-SGMII cases. The phy_set_mode_ext() call is made unconditionally. It cannot cause issues on platforms where !bp->phy or !bp->phy->ops->set_mode as, in those cases, the call is a no-op (returning zero). From reading upstream DTS, we can figure out that no platform has a bp->phy and a PHY driver that has a .set_mode() implementation: - cdns,zynqmp-gem: no DTS upstream. - microchip,mpfs-macb: microchip/mpfs.dtsi, &mac0..1, no PHY attached. - xlnx,versal-gem: xilinx/versal-net.dtsi, &gem0..1, no PHY attached. - xlnx,zynqmp-gem: xilinx/zynqmp.dtsi, &gem0..3, PHY attached to drivers/phy/xilinx/phy-zynqmp.c which has no .set_mode(). Reviewed-by: Maxime Chevallier Signed-off-by: Théo Lebrun Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-5-af509422c204@bootlin.com Signed-off-by: Paolo Abeni

net: macb: rename bp->sgmii_phy field to bp->phy

2025-10-28T14:17:54Z

The bp->sgmii_phy field is initialised at probe by init_reset_optional() if bp->phy_interface == PHY_INTERFACE_MODE_SGMII. It gets used by: - zynqmp_config: "cdns,zynqmp-gem" or "xlnx,zynqmp-gem" compatibles. - mpfs_config: "microchip,mpfs-macb" compatible. - versal_config: "xlnx,versal-gem" compatible. Make name more generic as EyeQ5 requires the PHY in SGMII & RGMII cases. Drop "for ZynqMP SGMII mode" comment that is already a lie, as it gets used on Microchip platforms as well. And soon it won't be SGMII-only. Reviewed-by: Andrew Lunn Reviewed-by: Maxime Chevallier Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-4-af509422c204@bootlin.com Signed-off-by: Paolo Abeni

net: macb: add no LSO capability (MACB_CAPS_NO_LSO)

2025-10-28T14:17:54Z

LSO is runtime-detected using the PBUF_LSO field inside register DCFG6. Allow disabling that feature if it is broken by using bp->caps coming from match data. Reviewed-by: Andrew Lunn Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-3-af509422c204@bootlin.com Signed-off-by: Paolo Abeni

net: macb: match skb_reserve(skb, NET_IP_ALIGN) with HW alignment

2025-10-28T14:17:54Z

If HW is RSC capable, it cannot add dummy bytes at the start of IP packets. Alignment (ie number of dummy bytes) is configured using the RBOF field inside the NCFGR register. On the software side, the skb_reserve(skb, NET_IP_ALIGN) call must only be done if those dummy bytes are added by the hardware; notice the skb_reserve() is done AFTER writing the address to the device. We cannot do the skb_reserve() call BEFORE writing the address because the address field ignores the low 2/3 bits. Conclusion: in some cases, we risk not being able to respect the NET_IP_ALIGN value (which is picked based on unaligned CPU access performance). Signed-off-by: Théo Lebrun Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20251023-macb-eyeq5-v3-2-af509422c204@bootlin.com Signed-off-by: Paolo Abeni

net: macb: Remove duplicate linux/inetdevice.h header

2025-10-22T01:40:04Z

./drivers/net/ethernet/cadence/macb_main.c: linux/inetdevice.h is included more than once. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=26474 Signed-off-by: Jiapeng Chong Acked-by: Nicolas Ferre Link: https://patch.msgid.link/20251020014441.2070356-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Jakub Kicinski

net: macb: sort #includes

2025-10-16T23:59:28Z

Sort #include preprocessor directives. Reviewed-by: Andrew Lunn Reviewed-by: Sean Anderson Signed-off-by: Théo Lebrun Link: https://patch.msgid.link/20251014-macb-cleanup-v1-15-31cd266e22cd@bootlin.com Signed-off-by: Jakub Kicinski