When in PCI mode, the GCB soft reset issued by the reset controller can latch spurious bits in the FDMA error stickies. The latched bits sit in FDMA_INTR_ERR until the FDMA IRQ is requested later in probe, at which point the handler fires immediately and WARNs. Clear FDMA_ERRORS, FDMA_INTR_ERR and FDMA_INTR_DB right after the switch reset so the FDMA comes out clean and the IRQ handler does not see ghost errors on probe. The clear runs on both the PCI and platform paths. On the platform path it has no effect — there are no spurious stickies to clear — but keeping it unconditional avoids a PCI-specific code path here. Tested-by: Herve Codina Signed-off-by: Daniel Machon --- drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c index ff3c6c76f16c..f6d64323d06c 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c @@ -1066,6 +1066,15 @@ static int lan966x_reset_switch(struct lan966x *lan966x) reset_control_reset(switch_reset); + /* When in PCI mode, the GCB soft reset issued by the reset + * controller can latch spurious bits in the FDMA error stickies. + * Clear them before request_irq hooks up the FDMA IRQ line, + * otherwise the handler fires immediately on probe. + */ + lan_wr(lan_rd(lan966x, FDMA_ERRORS), lan966x, FDMA_ERRORS); + lan_wr(lan_rd(lan966x, FDMA_INTR_ERR), lan966x, FDMA_INTR_ERR); + lan_wr(lan_rd(lan966x, FDMA_INTR_DB), lan966x, FDMA_INTR_DB); + /* Don't reinitialize the switch core, if it is already initialized. In * case it is initialized twice, some pointers inside the queue system * in HW will get corrupted and then after a while the queue system gets -- 2.34.1