Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp562973yba; Mon, 1 Apr 2019 11:55:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+BwaiXAxxFzQpNPksh88C156qYt2qoVEr3m96veCoTQ0hRo0dwiv0Edtr3ZpymI/qe9vk X-Received: by 2002:a17:902:8a8a:: with SMTP id p10mr8094244plo.8.1554144953343; Mon, 01 Apr 2019 11:55:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554144953; cv=none; d=google.com; s=arc-20160816; b=pfJdkLbuP9ASqB0vBbBLowxg6IP/8rGGBxPKcGsUsP89yrrM7U9MkZLQsnG1lK225G m4Z+m1fqPVfuDBvP1oRW6zYdYw0+eKU38rGMjQ5+BPXYwsMLB7xmc2eZr6LSquHNmQdk RhhaUTYqROlTckZV7DJ8HuAaQpAIf5ESxRYneg/gMOq5M6UkAXADanjcV51yoEEEb0lm 2who5NFyafC3OD+pGLBkFCzQotb6H8hW5diS31TKMOojDEEw1UDcVP6qTnQzqcp5nB/4 AeoX/m7DcXFa0Rw21+FTCDE+PCz2+61z3QHLsdIU72QftkSlpAzWRbDB+dKGBdXDb5A1 7wlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=QgCYX/FtuICfUZv4ojJiwZI57z8k6dq9L/vIDzsrJss=; b=diXavP/qictE9R86vNgH0F5CqbwHsFpfNqxBXk4ZxUG0n9jcji/uZ1vtWia5XSI9F4 5umdNdl67omnbUAcLCQSB2UyBhVcsRBEAE0OiRWIsnj+/7mMV993pPzJJHTWGsY3aOIn UMPRvE3gxU+NlFWuunngb9gj1TUxq2PKgeoFMErVYmCYVJ5qI7AaC1YmNMMwe+HpKJec gJ47fAmbNREJDbEPvT0GsVKZ60Noe12cAOP3fAT4KOD5y/QvnQmWVGvmBm5KmAipbThF NTpJ+pblxIYo3qfpIh6dtn1TAlKMi5TtEkZJvGhgzZkCTQ2n0Q637AuhKNT1QyB3t4vW /Tjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e10si9240582plt.283.2019.04.01.11.55.37; Mon, 01 Apr 2019 11:55:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729251AbfDASyu (ORCPT + 99 others); Mon, 1 Apr 2019 14:54:50 -0400 Received: from foss.arm.com ([217.140.101.70]:40682 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728690AbfDASyt (ORCPT ); Mon, 1 Apr 2019 14:54:49 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C1F6680D; Mon, 1 Apr 2019 11:54:48 -0700 (PDT) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 50CD83F59C; Mon, 1 Apr 2019 11:54:47 -0700 (PDT) Subject: Re: [PATCH 1/2] stmmac: introduce flag to dynamically disable TX offload for rockchip devices To: "Leonidas P. Papadakos" , Maxime Coquelin , Alexandre Torgue , Heiko Stuebner Cc: netdev@vger.kernel.org, Jose Abreu , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20190401181840.31255-1-papadakospan@gmail.com> From: Robin Murphy Message-ID: <9d65a22a-2288-dc53-0059-ec4a31424dd8@arm.com> Date: Mon, 1 Apr 2019 19:54:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190401181840.31255-1-papadakospan@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/04/2019 19:18, Leonidas P. Papadakos wrote: > From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= > > Some rockchip boards exhibit an issue where tx checksumming does not work with > packets larger than 1498. Is it really a board-level problem? I'm no networking expert, but the nature of the workaround suggests this is more likely to be some inherent limitation of the IP block in the SoC, rather than something to do with how the external pins get wired up. Does anyone have an RK3328 or RK3399 board that provably *does* checksum large packets correctly? > This is bad for network stability. > > The previous approach was using force_thresh_dma_mode in the board dts, which > does more than we need. If indeed it is a SoC-level thing (or at least we want to treat it as such), then couldn't we just hang it off the existing SoC-specific compatibles in dwmac-rk.c and avoid the need for a new DT property at all? After all, that's precisely why SoC-specific compatibles are a thing in the first place. Robin. > Signed-off-by: Leonidas P. Papadakos > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++ > drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++ > include/linux/stmmac.h | 1 + > 3 files changed, 7 insertions(+) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index 6a2e1031a..4552147e9 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -3660,6 +3660,10 @@ static netdev_features_t stmmac_fix_features(struct net_device *dev, > if (priv->plat->bugged_jumbo && (dev->mtu > ETH_DATA_LEN)) > features &= ~NETIF_F_CSUM_MASK; > > + /* Including very small MTUs of 1498 for Rockchip devices */ > + if (priv->plat->bugged_tx_coe && (dev->mtu > ETH_DATA_LEN - 2)) > + features &= ~NETIF_F_CSUM_MASK; > + > /* Disable tso if asked by ethtool */ > if ((priv->plat->tso_en) && (priv->dma_cap.tsoen)) { > if (features & NETIF_F_TSO) > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > index 3031f2bf1..807cf5826 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > @@ -519,6 +519,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac) > pr_warn("force_sf_dma_mode is ignored if force_thresh_dma_mode is set."); > } > > + plat->bugged_tx_coe = of_property_read_bool(np, "rockchip,bugged_tx_coe"); > + > of_property_read_u32(np, "snps,ps-speed", &plat->mac_port_sel_speed); > > plat->axi = stmmac_axi_setup(pdev); > diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h > index 4335bd771..60c411f43 100644 > --- a/include/linux/stmmac.h > +++ b/include/linux/stmmac.h > @@ -162,6 +162,7 @@ struct plat_stmmacenet_data { > int pmt; > int force_sf_dma_mode; > int force_thresh_dma_mode; > + int bugged_tx_coe; > int riwt_off; > int max_speed; > int maxmtu; >