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

[David Laight <david.laight.linux@gmail.com>]

On Thu, 20 Aug 2026 10:38:53 +1000
James <aslan.jnn@gmail.com> 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 <david.laight.linux@gmail.com> wrote:
> > 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.  
>