Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4871722ybl; Mon, 13 Jan 2020 22:55:58 -0800 (PST) X-Google-Smtp-Source: APXvYqyK5PBtSRgBzTV/TR+V8JhCLgq6m11hnbnKyl1tPuZ1iCY7XT4o+QDNyL7yJVcnlSgNHYx5 X-Received: by 2002:a9d:6f85:: with SMTP id h5mr16197372otq.19.1578984958546; Mon, 13 Jan 2020 22:55:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578984958; cv=none; d=google.com; s=arc-20160816; b=0ybRz7RCOdbyOhg1K0SL+A7/UVO49h+4qhXjC8UVRzNmtNhU62iEb1OPJw+9yuRCrY HEDUJT82gXIy31ia+qI8c6r8RssUJtHNV1pwkZIFJNn/3GqQNtpA1Lm2XqV+ZcUE/VrQ 5C3/wk5aqFf3j5nQZRmXWdgk0ynlrlDgrqLRMDbE/Dz/QZeQpc+9DeeiVL4PU9Wfm/gR 4nWiGyId9CC9KwXEVm+cPxsbtRCPYINYcramE3E3Ffn/5q+aCb67Jchad8/XcKZAElRr 4WOuViuLtXGzah9u471hyZQzsldubLHl9JS1+8uxOPLpp6w14sHp24aIsrv1EXGfuIum TuFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=uhe9WtvNLorImImLpDTjXJc6V5DRezqjB3HLKhakzL0=; b=WVGuPS68p1V1zFKjisjJDA5K6KHzAvytbpA1YE7ImrYLu7qI+GlOUKLojRUcIYUYav HLHSZnv/+NMdGCfBiknJ4pvywn7cNK5tO0HxI4ITMj1U0iitjcvjc1b9k1FFCTZ9m5Mg pCQdVxTo7cLDAJimABrgPS/KDgpVxcVKBpyhKkbjmVK9u9NPVt5fYqDdYSIBNgm92+0Z ZN4zwJjtnytlt4MK4QSwIkx56dBb2zMmN9oPtv1idvT9lmYUZhM3XMEEw7KusF5n2TlY 47mm/G7QPkMOphhhY8oqrfObPpy2scPSQJr8PyzcVu2PyUhZSfwa8HEhPwJb8N4kNMTK jTww== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si8272018otn.155.2020.01.13.22.55.47; Mon, 13 Jan 2020 22:55:58 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728831AbgANGye convert rfc822-to-8bit (ORCPT + 99 others); Tue, 14 Jan 2020 01:54:34 -0500 Received: from mga12.intel.com ([192.55.52.136]:47936 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726995AbgANGye (ORCPT ); Tue, 14 Jan 2020 01:54:34 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2020 22:54:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,431,1571727600"; d="scan'208";a="305065519" Received: from pgsmsx113.gar.corp.intel.com ([10.108.55.202]) by orsmga001.jf.intel.com with ESMTP; 13 Jan 2020 22:54:30 -0800 Received: from pgsmsx110.gar.corp.intel.com (10.221.44.111) by pgsmsx113.gar.corp.intel.com (10.108.55.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 14 Jan 2020 14:54:30 +0800 Received: from pgsmsx114.gar.corp.intel.com ([169.254.4.192]) by PGSMSX110.gar.corp.intel.com ([169.254.13.252]) with mapi id 14.03.0439.000; Tue, 14 Jan 2020 14:54:29 +0800 From: "Ong, Boon Leong" To: Jose Abreu , "netdev@vger.kernel.org" CC: Giuseppe Cavallaro , Alexandre Torgue , "David S . Miller" , "Maxime Coquelin" , "Tan, Tee Min" , "Voon, Weifeng" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH net 1/7] net: stmmac: fix error in updating rx tail pointer to last free entry Thread-Topic: [PATCH net 1/7] net: stmmac: fix error in updating rx tail pointer to last free entry Thread-Index: AQHVyfokBfT9czhzrkq4pJYkkv91Cqfn3pcAgAHSG5A= Date: Tue, 14 Jan 2020 06:54:29 +0000 Message-ID: References: <1578967276-55956-1-git-send-email-boon.leong.ong@intel.com> <1578967276-55956-2-git-send-email-boon.leong.ong@intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >From: Ong Boon Leong >Date: Jan/14/2020, 02:01:10 (UTC+00:00) > >> DMA_CH(#i)_RxDesc_Tail_Pointer points to an offset from the base and >> indicates the location of the last valid descriptor. >> >> The change introduced by "net: stmmac: Update RX Tail Pointer to last >> free entry" incorrectly updates the RxDesc_Tail_Pointer and causess >> Rx operation to freeze in corner case. The issue is explained as >> follow:- >> >> Say, cur_rx=1 and dirty_rx=0, then we have dirty=1 and entry=0 before >> the while (dirty-- > 0) loop of stmmac_rx_refill() is entered. When >> the while loop is 1st entered, Rx buffer[entry=0] is refilled and after >> entry++, then, entry=1. Now, the while loop condition check "dirty-- > 0" >> and the while loop bails out because dirty=0. Up to this point, the >> driver code works correctly. >> >> However, the current implementation sets the Rx Tail Pointer to the >> location pointed by dirty_rx, just updated to the value of entry(=1). >> This is incorrect because the last Rx buffer that is refileld with empty >> buffer is with entry=0. In another words, the current logics always sets >> Rx Tail Pointer to the next Rx buffer to be refilled (too early). >> >> So, we fix this by tracking the index of the most recently refilled Rx >> buffer by using "last_refill" and use "last_refill" to update the Rx Tail >> Pointer instead of using "entry" which points to the next dirty_rx to be >> refilled in future. > >I'm not sure about this ... > >RX Tail points to last valid descriptor but it doesn't point to the base >address of that one, it points to the end address. > >Let's say we have a ring buffer with just 1 descriptor. With your new >logic then: RX base == RX tail (== RX base), so the IP will not see any >descriptor. But with old logic: RX base == (RX base + 1), which causes >the IP to correctly see the descriptor. > >Can you provide more information on the Rx operation freeze you >mentioned ? Can it be another issue ? I recheck on my side, it seems like the fix needed for simics model at my end and not needed for actual SoC. This is strange but I can check internal team. I also read through the databook which says that for 40-bit or 48-bit addressing mode, the tail pointer must be advanced to the location immediately after the descriptors are set, for the DMA to know that additional descriptors are available. Now, relooking at the current logic which sets the rx tail pointer according to the value of "dirty_rx" which can be "zero" as it takes value from entry that is incremented through STMMAC_GET_ENTRY(entry, DMA_RX_SIZE). This too can give a situation that the base and tail registers is pointing to the same location. According to SNPS databook, the DMA engine goes into SUSPEND state if the Rx descriptors are not OWN=1. The operation can be resumed by ensuring that the descriptors are owned by the DMA and then update the tail pointer. What is your opinion here if we always update the Rx tail pointer to pointer the boundary of the DMA size as follow without depending on dirty_rx. rx_q->rx_tail_addr = rx_q->dma_rx_phy + (DMA_RX_SIZE * sizeof(struct dma_desc)) Thanks Boon Leong