> On 10/13/26 17:33, Lorenzo Bianconi wrote:
> > > Thank you for your contribution! Sashiko AI review found more severe
> > > issue(s) in other patches of this series. This mail is only an FYI, in case
> > > you want to address the nit picks below when you respin.
> > > 
> > > Low priority / nit picks for your consideration:
> > > 
> > > - [Low] The commit message's premise doesn't match the tree.
> > > 
> > > Pre-existing issues:
> > > - [Medium] This problem wasn't introduced by this patch, but
> > >    stmmac_xdp_xmit_xdpf() never looks at priv->plat->tx_coe when deciding…
> > > 
> > > --
> > > 
> > > net: stmmac: disable TX checksum offload for jumbo frames on bugged cores
> > > 
> > > This patch turns off TX checksum insertion in stmmac_xdp_xmit_xdpf() for
> > > frames longer than ETH_FRAME_LEN on bugged_jumbo cores. It is meant to
> > > match the stmmac_fix_features() workaround that the skb path already uses.
> > > 
> > > > The XDP TX
> > > > path bypasses that workaround, so once XDP is allowed at MTU >
> > > > ETH_DATA_LEN, jumbo frames sent via XDP_TX or redirected into the
> > > > device would leave the interface with a full checksum insertion enabled
> > > > on those cores - exactly what the workaround is meant to avoid.
> > > 
> > > [Severity: Low]
> > > Can this scenario happen in the current tree? XDP still can't be used with
> > > a jumbo MTU. stmmac_xdp_set_prog() refuses to attach a program when the MTU
> > > is above ETH_DATA_LEN:
> > 
> > This is actually a preliminary fix needed to remove the MTU limitation when the
> > device is running in XDP mode.
> The point is that this patch does not address any issues, no it should not
> include a fixes tag. I'll drop it while applying the series.

ack, thx Paolo for fixing it.

Regards,
Lorenzo

> 
> Also a more explicative cover letter would have helped.
> 
> No need to repost.
> 
> Thanks,
> 
> Paolo
>