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

On Mon, Aug 17, 2026 at 4:32:43PM -0700, Jakub Kicinski [off-list ref] wrote:

This is an AI-generated review of your patch. The human sending this
email says "If AI is right about other error frame types it may be
better to program them all in one commit to avoid a behavior change
if someone needs the other bad frames later"
...

Hi Jakub, thanks a lot for your review!

Thank you for catching the possible race between the current feature update
path with the service-work RX re-enable path: `ndo_set_features()` programs
DCRCC before it commits `netdev_features`, while `xgbe_enable_rx()` reads
`netdev_features`. The non-atomic read-modify-write accesses to `MAC_RCR`
also make the final register value unreliable when those paths overlap.
Apologise that I've missed this.

Also taking Simon's earlier input into account, I think the best approach
for now is to set the default DCRCC value to 0, so that this network
controller can become more consistent with most other network controllers
and also with respect to user expectations. In particular, I would not
expect users to receive packets with bad FCS by default.

I will therefore drop the RXALL mechanism altogether for now (the updated,
trimmed down patch, will follow later). We can revisit this later and
implement proper RXALL support (under `net-next`, as Simon mentioned),
potentially including additional features beyond allowing packets with bad
FCS to come in.

Regards,
James