Re: Dealing with M_HASFCS for protocols that do not do ethernet crc

[Martin Husemann <martin%duskware.de@localhost>]

On Wed, Aug 10, 2022 at 08:48:02AM +0900, Chris wrote:
> Removing AWIN_GMAC_MAC_CONF_ACS from interface configuration, and reverting
> the per-protocol FCS bit I committed, appears to do the right thing.  AppleTalk
> works, IP works, and the rockpro64 hasn't fallen over after four hours of
> moderate testing.
> 
> I'm going to commit this fix right after I finish writing this email.  Martin,
> would this pass muster for a pullup to the 9.x branch?

Yes, I was going to suggest exactly trying that - thanks for testing!

This was kinda a fools erand - for the archive here the summary:

 - The driver configured the chip (due to missing/incomplete/incorrect)
   documentation to NOT strip FCS from all "regular" packets (frame
   length field <= 1500) but to strip it from packets with that field
   used as ethertype (with type >= 0x600).
   The driver (not being aware of the difference) set M_HASFCS for all
   packets (whether stripped by hardware or not).

 - The original commit that started this thread worked around the difference
   manually (still not understanding the full issue).

 - The real fix (as described above by Chris) of course is to configure the
   hardware to always strip off FCS and never set M_HASFCS.

In general we seem to agree that:

 - a driver should try to set the hardware to strip FCS always
 - only if that is not possible, the driver sets M_HASFCS
 - a driver does not have to care about ethernet packet types (unless
   there are driver or hardware bugs, see above)

Martin