summaryrefslogtreecommitdiff
path: root/kernel/livepatch
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2026-10-28 16:12:38 -0700
committerJakub Kicinski <kuba@kernel.org>2026-10-28 16:12:38 -0700
commit775fede6a939d7e7564d9cbb28393ef8fe15a936 (patch)
treeef03aa5f173ccb2e92a92ed935e70afce60422da /kernel/livepatch
parentfd1436a75ceb07c7029be02f89e8a1b34a6978c8 (diff)
parentff8a7c0c06762a2a2333fbd6148d637bbd3d5090 (diff)
Merge branch 'net-bcmgenet-fixes-for-a-failed-resume-and-the-ring-rebuild'
Nicolai Buchwitz says: ==================== net: bcmgenet: fixes for a failed resume and the ring rebuild Mostly findings sashiko raised during my recent review sessions. Patch 1 is a resume that fails in bcmgenet_init_dma(), which leaves the interface up with no datapath and the next ifdown hanging in napi_disable() with RTNL held. It is one patch because nothing that resume leaves behind is reachable on its own, the second suspend never returns until the hang is fixed. Patch 2 (was patch 4 in v1) is the Tx coalescing threshold going back to the driver default whenever the rings are rebuilt. Patch 1 fixes the rebuild path, not the root cause. bcmasp for example parks the PHY in its WoL suspend and has one deinit with a flag, which looks like the direction for genet too. But one step at a time :) It is also prep for the next version of my MTU series [1], which drops the "hallmark of a bad design" flag in favour of the ring pointers it clears. [1] https://patch.msgid.link/20261013-nb-genet-mtu-nn-v2-v5-0-076b6fc240be@tipi-net.de For backports: the WoL hunks in patch 1 need 254f3239dd07, on older trees they can be dropped. The rest should apply on its own. Tested on BCM2711 (Raspberry Pi CM4) with the resume allocation forced to fail. BCM2711 has no WoL irq, so I had to force the capability. With this a magic packet wakes the board and the interface recovers on the next suspend and resume. Thanks to Florian for pointing out that s2idle can do this at all. WoL doesn't wake the board after a failed resume though: as sashiko pointed out init_umac() left UMAC_CMD at 10 Mb/s and only adjust_link puts it back, so it arms fine and then misses the packet. But this is pre-existing, arguably even better since it no longer hangs the system like before. IMHO the proper fix is to let resume allocate before it touches the hardware ... I'll do that after the MTU series. ==================== Link: https://patch.msgid.link/20261022-nb-genet-fini-dma-net-v3-0-6e9fc89c0156@tipi-net.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'kernel/livepatch')
0 files changed, 0 insertions, 0 deletions