mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-22 12:14:01 +08:00
f5b720b859
For each Rx frame the eTSEC writes its FCS (Frame Check Sequence) to the Rx buffer. The eTSEC h/w manual states in the "Receive Buffer Descriptor Field Descriptions" table: "Data length is the number of octets written by the eTSEC into this BD's data buffer if L is cleared (the value is equal to MRBLR), or, if L is set, the length of the frame including *CRC*, FCB (if RCTRL[PRSDEP > 00), preamble (if MACCFG2[PreAmRxEn]=1), time stamp (if RCTRL[TS] = 1) and any padding (RCTRL[PAL])." Though the FCS bytes are removed by the driver before passing the skb to the net stack, the Rx buffer size computation does not currently take into account the FCS bytes (4 bytes). Because the Rx buffer size is multiple of 512 bytes, leaving out the FCS is not a problem for the default MTU of 1500, as the Rx buffer size is 1536 in this case. However, for custom MTUs, where the difference between the MTU size and the Rx buffer size is less, this can be a problem as the computed Rx buffer size won't be enough to accomodate the FCS for a received frame that is big enough (close to MTU size). In such case the received frame is considered to be incomplete (L flag not set in the RxBD status) and silently dropped. Note that the driver does not currently support S/G on Rx, so it has to compute its Rx buffer size based on the MTU of the device. Reported-by: Kristian Otnes <kotnes@cisco.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| fs_enet | ||
| fec_main.c | ||
| fec_mpc52xx_phy.c | ||
| fec_mpc52xx.c | ||
| fec_mpc52xx.h | ||
| fec_ptp.c | ||
| fec.h | ||
| fsl_pq_mdio.c | ||
| gianfar_ethtool.c | ||
| gianfar_ptp.c | ||
| gianfar.c | ||
| gianfar.h | ||
| Kconfig | ||
| Makefile | ||
| ucc_geth_ethtool.c | ||
| ucc_geth.c | ||
| ucc_geth.h | ||
| xgmac_mdio.c | ||