On Tue, 16 Jan 2024 13:14:15 +0100 (CET) Romain Gantois wrote:
@@ -4997,7 +5020,7 @@ static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue, stmmac_rx_vlan(priv->dev, skb); skb->protocol = eth_type_trans(skb, priv->dev);
- if (unlikely(!coe))
- if (unlikely(!coe) || !stmmac_has_ip_ethertype(skb))
The lack of Rx side COE checking in this driver is kinda crazy. Looking at enh_desc_coe_rdes0() it seems like RDES0_FRAME_TYPE may be the indication we need here?
I don't think that RDES0_FRAME_TYPE would be enough, at least not on its own. That bit is set by checking the length/ethertype field to see if is an Ethernet II frame or an IEEE802.3 frame. But even Ethernet II frames with non-IP ethertypes will not be checksummed. Also protocols with a non-fixed ethertype field such as DSA_TAG_PROTO could trigger the bit, or not, depending on what they put in the DSA tag.
Hm, the comment in enh_desc_coe_rdes0() says:
/* bits 5 7 0 | Frame status * ---------------------------------------------------------- * 0 0 0 | IEEE 802.3 Type frame (length < 1536 octects) * 1 0 0 | IPv4/6 No CSUM errorS. * 1 0 1 | IPv4/6 CSUM PAYLOAD error * 1 1 0 | IPv4/6 CSUM IP HR error * 1 1 1 | IPv4/6 IP PAYLOAD AND HEADER errorS * 0 0 1 | IPv4/6 unsupported IP PAYLOAD * 0 1 1 | COE bypassed.. no IPv4/6 frame * 0 1 0 | Reserved. */
which makes it sound like bit 5 will not be set for a Ethernet II frame with unsupported IP payload, or not an IP frame. Does the bit mean other things in different descriptor formats?