Re: [PATCH net 0/7] net: bcm4908_enet: TX ring and DMA fixes

["Kordian Chmielewski (mlody1212)" <kudzo51@gmail.com>]

A correction to the cover letter and to two changelogs: I mixed up what
I had seen fail on the hardware with what I had found reading the code.

Only patches 1 and 7 come from failures on the hardware. Patch 1 fixes
the TX stall under load (seen twice, none in 8 runs with the fix).
Patches 2 to 6 come from reading the code and have no reproducer.

Patch 7: the skb_over_panic was seen only after I raised the RX
channel's MAX_BURST to 32 by hand on a running channel. I tried that
again today on my 6.18 tree with the patch: within seconds one frame
was longer than the buffer, and it was dropped and counted in
rx_length_errors instead of a panic, but the DMA then stalled and the
board needed a reboot. With the driver's own value, 8, there were none
in about 18 million frames. So patch 7 is hardening and belongs in
net-next rather than net.

Two changelogs say too much. In patch 3, the TX skbs left on stop are
leaked, not freed: the stale descriptors could send buffers nobody
freed. In patch 6, I have no test of what the DMA does at a descriptor
being refilled. With the patch, a 16-entry RX ring under more traffic
than the CPU can take gave no RX or checksum errors in about 14 million
frames, but I have not run that without the patch. Also, the panic in
patch 7 passed 3388 to skb_put(), so the descriptor said 3392 with the
FCS.

In my earlier plan mail I wrote that RX buffers were not freed on stop
and that RX frames longer than the buffer were passed up. Both were
wrong: the RX buffers are freed, only unmapped with a size of 0, and
such frames end in skb_over_panic, seen only with the raised burst.

I will send a v2 with these fixed.

Kordian