--- /dev/null
+From 99537d5c476cada9cf75aef9fa75579a31faadb9 Mon Sep 17 00:00:00 2001
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+Date: Mon, 22 Dec 2025 09:56:24 +0800
+Subject: net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()
+
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+
+commit 99537d5c476cada9cf75aef9fa75579a31faadb9 upstream.
+
+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 <kexin.hao@windriver.com>
+Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
+Link: https://patch.msgid.link/20251222015624.1994551-1-xiaolei.wang@windriver.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/cadence/macb_main.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/cadence/macb_main.c
++++ b/drivers/net/ethernet/cadence/macb_main.c
+@@ -777,7 +777,6 @@ static void macb_mac_link_up(struct phyl
+ /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
+ * cleared the pipeline and control registers.
+ */
+- bp->macbgem_ops.mog_init_rings(bp);
+ macb_init_buffers(bp);
+
+ for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue)
+@@ -2478,6 +2477,8 @@ static void gem_init_rings(struct macb *
+ unsigned int q;
+ int i;
+
++ bp->macbgem_ops.mog_init_rings(bp);
++
+ for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
+ for (i = 0; i < bp->tx_ring_size; i++) {
+ desc = macb_tx_desc(queue, i);
--- /dev/null
+From 1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5 Mon Sep 17 00:00:00 2001
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+Date: Thu, 18 Dec 2025 06:53:54 +0530
+Subject: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
+
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+
+commit 1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5 upstream.
+
+A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
+due to lock ordering inversion between device_lock and rfkill_global_mutex.
+
+The problematic lock order is:
+
+Thread A (rfkill_fop_write):
+ rfkill_fop_write()
+ mutex_lock(&rfkill_global_mutex)
+ rfkill_set_block()
+ nfc_rfkill_set_block()
+ nfc_dev_down()
+ device_lock(&dev->dev) <- waits for device_lock
+
+Thread B (nfc_unregister_device):
+ nfc_unregister_device()
+ device_lock(&dev->dev)
+ rfkill_unregister()
+ mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex
+
+This creates a classic ABBA deadlock scenario.
+
+Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
+device_lock critical section. Store the rfkill pointer in a local variable
+before releasing the lock, then call rfkill_unregister() after releasing
+device_lock.
+
+This change is safe because rfkill_fop_write() holds rfkill_global_mutex
+while calling the rfkill callbacks, and rfkill_unregister() also acquires
+rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
+wait for any ongoing callback to complete before proceeding, and
+device_del() is only called after rfkill_unregister() returns, preventing
+any use-after-free.
+
+The similar lock ordering in nfc_register_device() (device_lock ->
+rfkill_global_mutex via rfkill_register) is safe because during
+registration the device is not yet in rfkill_list, so no concurrent
+rfkill operations can occur on this device.
+
+Fixes: 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+4ef89409a235d804c6c2@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=4ef89409a235d804c6c2
+Link: https://lore.kernel.org/all/20251217054908.178907-1-kartikey406@gmail.com/T/ [v1]
+Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
+Link: https://patch.msgid.link/20251218012355.279940-1-kartikey406@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/core.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/net/nfc/core.c
++++ b/net/nfc/core.c
+@@ -1154,6 +1154,7 @@ EXPORT_SYMBOL(nfc_register_device);
+ void nfc_unregister_device(struct nfc_dev *dev)
+ {
+ int rc;
++ struct rfkill *rfk = NULL;
+
+ pr_debug("dev_name=%s\n", dev_name(&dev->dev));
+
+@@ -1164,13 +1165,17 @@ void nfc_unregister_device(struct nfc_de
+
+ device_lock(&dev->dev);
+ if (dev->rfkill) {
+- rfkill_unregister(dev->rfkill);
+- rfkill_destroy(dev->rfkill);
++ rfk = dev->rfkill;
+ dev->rfkill = NULL;
+ }
+ dev->shutting_down = true;
+ device_unlock(&dev->dev);
+
++ if (rfk) {
++ rfkill_unregister(rfk);
++ rfkill_destroy(rfk);
++ }
++
+ if (dev->ops->check_presence) {
+ del_timer_sync(&dev->check_pres_timer);
+ cancel_work_sync(&dev->check_pres_work);
--- /dev/null
+From fa0b198be1c6775bc7804731a43be5d899d19e7a Mon Sep 17 00:00:00 2001
+From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+Date: Sun, 21 Dec 2025 00:24:00 -0800
+Subject: net: usb: sr9700: fix incorrect command used to write single register
+
+From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+
+commit fa0b198be1c6775bc7804731a43be5d899d19e7a upstream.
+
+This fixes the device failing to initialize with "error reading MAC
+address" for me, probably because the incorrect write of NCR_RST to
+SR_NCR is not actually resetting the device.
+
+Fixes: c9b37458e95629b1d1171457afdcc1bf1eb7881d ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+Link: https://patch.msgid.link/20251221082400.50688-1-enelsonmoore@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/sr9700.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/usb/sr9700.c
++++ b/drivers/net/usb/sr9700.c
+@@ -52,7 +52,7 @@ static int sr_read_reg(struct usbnet *de
+
+ static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
+ {
+- return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
++ return usbnet_write_cmd(dev, SR_WR_REG, SR_REQ_WR_REG,
+ value, reg, NULL, 0);
+ }
+
+@@ -65,7 +65,7 @@ static void sr_write_async(struct usbnet
+
+ static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
+ {
+- usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
++ usbnet_write_cmd_async(dev, SR_WR_REG, SR_REQ_WR_REG,
+ value, reg, NULL, 0);
+ }
+