Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1249311yba; Tue, 2 Apr 2019 05:32:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzeQT9zw8iLm/VUYWmu9oe9bCZz1R7VS0Bpt2FLmqn3v2hOajoMxju+pEU+oORkVTd0VH8e X-Received: by 2002:a63:5a20:: with SMTP id o32mr63775752pgb.225.1554208347705; Tue, 02 Apr 2019 05:32:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554208347; cv=none; d=google.com; s=arc-20160816; b=WWfagkyxe+8YmO+BlOyL1aFKs3CJU16/FXYZDFEuBNIvuDN0ll37pyrJ2XjZQbxrny ussX0JbrAeaC56S+nhn9vZjVwTtHirGeHlzo3uVcUf62RCFta0or/PQMDAjc3XNf4thE yInCNgvq27aR1L+guofrCG24CSJmKjskv7mRqFEwsfkgWjU8/PDkzZzxlP1yesMP8xlI BCr5GjAQk9z6CJsgmNrtfucLmpac61vVfTGCy1RA+hY3gJySx/IAG2M03oj5R542g+U9 8XJ9xe1YU8HfAkRPOVl3WgH/Sy2XdXF5Nwdxz/xAColMd4GbvZ92AcXW2TYXUjL3cCEb aF6Q== 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=G3SvjniX092Rpri77cwEly3g3Z8rqiLvD2iphmUrXYA=; b=Ss7kDJIkpw1hhk1+MckUjpmnZ5e6kpBAMOn2aTG5d4r4GQpUCqn0Hay+4byF4hU7BP HeN5rnfXeyDTozoil6NB7y3B90L2lqYpBmqlHX2efP30U621aA1KgL2NJ+X2gowjM2ff c0Y3plIZdoVjY5GY72wS9R/qXgF0mwjxeVdsBKIxTUFzeSn6LHp6wc7gqMRJWZlzt/qr r0eLmR1cHY2BtEILbeGrN6gb6D8CxzL8GNltyXfmo2a8SBCPH1apc+RiHzFjHvSwDb/X hktU2JbcM2Ibaxi8SKeq3rh0oKx1qJr3ub95sG+Cj01RAOW5d+xtXeyKCtYZaMRyuFS9 MDuQ== 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 i18si10848483pfa.205.2019.04.02.05.32.11; Tue, 02 Apr 2019 05:32:27 -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 S1730810AbfDBLtk (ORCPT + 99 others); Tue, 2 Apr 2019 07:49:40 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49564 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726903AbfDBLtk (ORCPT ); Tue, 2 Apr 2019 07:49:40 -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 A982B374; Tue, 2 Apr 2019 04:49:39 -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 C34B73F59C; Tue, 2 Apr 2019 04:49:37 -0700 (PDT) Subject: Re: [PATCH 1/2] stmmac: introduce flag to dynamically disable TX offload for rockchip devices To: Jose Abreu , Philipp Tomsich , =?UTF-8?Q?Heiko_St=c3=bcbner?= , =?UTF-8?Q?Christoph_M=c3=bcllner?= Cc: "Leonidas P. Papadakos" , Maxime Coquelin , Alexandre Torgue , "netdev@vger.kernel.org" , LKML , Linux ARM , Klaus Goger References: <20190401181840.31255-1-papadakospan@gmail.com> <9d65a22a-2288-dc53-0059-ec4a31424dd8@arm.com> <2312344.mOsv7YkeBG@diego> <9EC67532-2D43-4AAD-BFA7-8B6797067427@theobroma-systems.com> <78EB27739596EE489E55E81C33FEC33A0B421348@de02wembxa.internal.synopsys.com> From: Robin Murphy Message-ID: <4a9839d6-3d90-4354-7b64-78d5c1126e99@arm.com> Date: Tue, 2 Apr 2019 12:49:36 +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: <78EB27739596EE489E55E81C33FEC33A0B421348@de02wembxa.internal.synopsys.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/04/2019 08:59, Jose Abreu wrote: > From: Philipp Tomsich > Date: Mon, Apr 01, 2019 at 20:12:21 > >> + Christoph. >> >>> On 01.04.2019, at 21:06, Heiko Stübner wrote: >>> >>> Am Montag, 1. April 2019, 20:54:45 CEST schrieb Robin Murphy: >>>> 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? >>> >>> I don't have that many rk3399-boards with actual ethernet and even only >>> the rock64 from rk3328-land, but at least my rk3399-firefly also seems >>> affected by this. >>> >>> But so far the rk3399-puma board from Theobroma did not show that ethernet >>> issue for me, so I've added two Theobroma people who may or may not tell >>> if they've also seen that issue. >>> >>>> >>>>> 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. >>>> > > This can happen when FIFO size + PBL settings are not big enough for COE. > > Can you please share the above settings ? Can the FIFO size be discovered by dumping registers, or does someone from Rockchip need to look up the IP configuration details? FWIW, taking a look at the RK3399 TRM, this (p788) jumps out: "PBL ... For TxFIFO, valid PBL range in full duplex mode and duplex mode is 128 or less. For RxFIFO, valid PBL range in full duplex mode is all." Does that suggest that it's worth fiddling with the "snps,txpbl" value in DT? Thanks, Robin.