net: aquantia: tcp checksum 0xffff being handled incorrectly

Thats a known quirk in windows tcp stack it can produce 0xffff checksum.
Thats incorrect but it is.

Atlantic HW with LRO enabled handles that incorrectly and changes csum to
0xfffe - but indicates that csum is invalid. This causes driver to pass
packet to linux networking stack with CSUM_NONE, stack eventually drops
the packet.

There is a quirk in atlantic HW to enable correct processing of
0xffff incorrect csum. Enable it.

The visible bug is that windows link partner with software generated csums
caused TCP connection to be unstable since all packets that csum value
are dropped.

Reported-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
Signed-off-by: Nikita Danilov <ndanilov@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
index e979f22..5c3065b 100644 (file)
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
@@ -266,12 +266,11 @@ static int hw_atl_b0_hw_offload_set(struct aq_hw_s *self,
                 */
                hw_atl_rpo_lro_max_coalescing_interval_set(self, 50);
 
-
                hw_atl_rpo_lro_qsessions_lim_set(self, 1U);
 
                hw_atl_rpo_lro_total_desc_lim_set(self, 2U);
 
-               hw_atl_rpo_lro_patch_optimization_en_set(self, 0U);
+               hw_atl_rpo_lro_patch_optimization_en_set(self, 1U);
 
                hw_atl_rpo_lro_min_pay_of_first_pkt_set(self, 10U);