Re: [PATCH net] net: amd-xgbe: support receiving packets with bad FCS

On Thu, 20 Aug 2026 10:38:53 +1000
James [off-list ref] wrote:

Hi David, thank you for your feedback!

So on my test hardware (AMD Snowy Owl SoC), it is the former: FCS
validation is actually disabled, and packets with bad FCS are processed as
valid packets.

So the subject should be:
net:amd-xgbe: discard rx packets with bad FCS

I'd also guess that you don't need to support NETIF_F_RXALL.

Parts of the driver I've just looked at are actually horrid.

All the RMW on MAC_RCR (etc) are just silly any may leave the hardware
with inconsistent settings, the code should really cache the value and
just do writes.
It might be sensible to set RE last as a separate write (done), but it
really does need to be cleared first.

Then there are all the function pointers - I failed to see anywhere that
would set alternate functions.

	David

Concretely, with DCRCC=1 (the current behavior):

  - `xgbe_dev_read()` treats the packet as valid: the skb is passed up the
    stack normally (e.g. `tcpdump -Q in` will see the packets with
    bad FCS).
  - The RX CRC error counter is not incremented, so `ethtool -S` shows no
    error.
  - Since CST=1 (CRC stripping) is also set, the FCS bytes are stripped
    and are not visible in the captured frame from user-space, thus
    user space can't tell if the packet got bad FCS or not).

I verified this empirically: if the link partner sends two identical
packets, one with a valid FCS and one with a completely inverted FCS, both
arrive identically in `tcpdump -Q in` with no way to distinguish them, and
`ethtool -S` shows zero CRC errors.

With the patch applied (e.g. setting DCRCC=0), the bad-FCS packet is
dropped and RX CRC counter will get incremented.

Regards,
James

On Wed, Aug 19, 2026 at 12:43:07PM +0100, David Laight [off-list ref] wrote:

quoted

What actually happens to packets with bad FCS?
If FCS validation is actually disabled they'd get processed as valid packets.
That would be a serious bug.
OTOH the rx status could contain an 'fcs error' bit that causes the packet
be discarded and the software counts an error.
That would match the historic behaviour of many ethernet chips.