diff options
| author | Jakub Kicinski <kuba@kernel.org> | 2026-10-28 16:12:38 -0700 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-10-28 16:12:38 -0700 |
| commit | 775fede6a939d7e7564d9cbb28393ef8fe15a936 (patch) | |
| tree | ef03aa5f173ccb2e92a92ed935e70afce60422da /tools/workqueue | |
| parent | fd1436a75ceb07c7029be02f89e8a1b34a6978c8 (diff) | |
| parent | ff8a7c0c06762a2a2333fbd6148d637bbd3d5090 (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 'tools/workqueue')
0 files changed, 0 insertions, 0 deletions
