net: xilinx: axienet: Query about checksum partial implementation
Simon Horman
horms at kernel.org
Fri Jul 26 05:07:00 PDT 2024
Hi Radhey, all,
I am wondering if you could shed some light on the following
checksum partial handling in the axienet_rx_poll():
/* if we're doing Rx csum offload, set it up */
if (lp->features & XAE_FEATURE_FULL_RX_CSUM) {
...
} else if ((lp->features & XAE_FEATURE_PARTIAL_RX_CSUM) != 0 &&
skb->protocol == htons(ETH_P_IP) &&
skb->len > 64) {
skb->csum = be32_to_cpu(cur_p->app3 & 0xFFFF);
...
}
In particluar the "skb->csum =" line.
The type of cur_p->app3 is u32, and 0xFFFF is also host byte order.
So far so good. But after the bitwise operation it is treated
as a big-endian value by passing it to be32_to_cpu.
Perhaps I am missing something obvious, but my question is how does that work?
* Was it only tested on big endian sysgtems where be32_to_cpu() is a no-op
* Was it only tested on little endian systems where be32_to_cpu()
is a byteswap and somehow that works (how?).
* Is the code unecessised because the XAE_FEATURE_FULL_RX_CSUM branch is
always taken?
A grep of dts files shows up arch/microblaze/boot/dts/system.dts which
sets sets xlnx,rxcsum to 0, which corresponds to XAE_NO_CSUM_OFFLOAD.
* Something else
Flagged by Sparse
The in quesoitn code seems to have been introduced by
8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
More information about the linux-arm-kernel
mailing list