On 1/5/26 1:23 PM, Parvathi Pudi wrote:

+static int icssm_prueth_ndev_port_link(struct net_device *ndev,
+				       struct net_device *br_ndev)
+{
+	struct prueth_emac *emac = netdev_priv(ndev);
+	struct prueth *prueth = emac->prueth;
+	unsigned long flags;
+	int ret = 0;
+
+	dev_dbg(prueth->dev, "%s: br_mbrs=0x%x %s\n",
+		__func__, prueth->br_members, ndev->name);
+
+	spin_lock_irqsave(&emac->addr_lock, flags);
+
+	if (!prueth->br_members) {
+		prueth->hw_bridge_dev = br_ndev;
+	} else {
+		/* This is adding the port to a second bridge,
+		 * this is unsupported
+		 */
+		if (prueth->hw_bridge_dev != br_ndev) {
+			spin_unlock_irqrestore(&emac->addr_lock, flags);
+			return -EOPNOTSUPP;
+		}
+	}
+
+	prueth->br_members |= BIT(emac->port_id);
+
+	ret = icssm_prueth_port_offload_fwd_mark_update(prueth);

More AI generated feedback here that still looks valid to me:

"""
ndo_stop() can sleep (e.g., via rproc_shutdown()). This function appears
to be called while holding a spinlock via the call chain:

  icssm_prueth_ndev_port_link()
    -> spin_lock_irqsave(&emac->addr_lock)
      -> icssm_prueth_port_offload_fwd_mark_update()
        -> icssm_prueth_change_mode()
          -> ndo_stop() / ndo_open()

Is this intentional? The ndo_open() path also calls
icssm_prueth_sw_init_fdb_table() which does kmalloc(GFP_KERNEL) and
rproc_boot(), both of which may sleep.
"""

There are other similar cases; for the full report see:

https://netdev-ai.bots.linux.dev/ai-review.html?id=ce23f731-f25b-4082-a5d0-c1261ab829ed

/P