On 08.04.2021 20:00, George McCollister wrote: > On Thu, Apr 8, 2021 at 12:46 PM Sven Van Asbroeck <thesve...@gmail.com> wrote: >> >> Hi George, >> >> On Thu, Apr 8, 2021 at 1:36 PM George McCollister >> <george.mccollis...@gmail.com> wrote: >>> >>> Can you explain the difference in behavior with what I was observing >>> on the LAN7431? >> >> I'm not using DSA in my application, so I cannot test or replicate >> what you were observing. It would be great if we could work together >> and settle on a solution that is acceptable to both of us. > > Sounds good. > >> >>> I'll retest but if this is reverted I'm going to start >>> seeing 2 extra bytes on the end of frames and it's going to break DSA >>> with the LAN7431 again. >>> >> >> Seen from my point of view, your patch is a regression. But perhaps my >> patch set is a regression for you? Catch 22... >> >> Would you be able to identify which patch broke your DSA behaviour? >> Was it one of mine? Perhaps we can start from there. > > Yes, first I'm going to confirm that what is in the net branch still > works (unlikely but perhaps something else could have broken it since > last I tried it). > Then I'll confirm the patch which I believe broke it actually did and > report back. > >> >> Sven
Just an idea: RX_HEAD_PADDING is an alias for NET_IP_ALIGN that can have two values: 0 and 2 The two systems you use may have different NET_IP_ALIGN values. This could explain the behavior. Then what I proposed should work for both of you: frame_length - ETH_FCS_LEN
