From patchwork Thu Nov 3 16:17:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexey Brodkin X-Patchwork-Id: 690906 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3t8qsj3Qg5z9svs for ; Fri, 4 Nov 2016 03:19:05 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758685AbcKCQSy (ORCPT ); Thu, 3 Nov 2016 12:18:54 -0400 Received: from smtprelay.synopsys.com ([198.182.47.9]:33610 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757882AbcKCQSx (ORCPT ); Thu, 3 Nov 2016 12:18:53 -0400 Received: from mailhost.synopsys.com (mailhost1.synopsys.com [10.12.238.239]) by smtprelay.synopsys.com (Postfix) with ESMTP id 35DD224E139C; Thu, 3 Nov 2016 09:18:51 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id E341832B; Thu, 3 Nov 2016 09:18:50 -0700 (PDT) Received: from us01wehtc1.internal.synopsys.com (us01wehtc1-vip.internal.synopsys.com [10.12.239.236]) by mailhost.synopsys.com (Postfix) with ESMTP id 4F1DD322; Thu, 3 Nov 2016 09:18:50 -0700 (PDT) Received: from DE02WEHTCA.internal.synopsys.com (10.225.19.92) by us01wehtc1.internal.synopsys.com (10.12.239.231) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 3 Nov 2016 09:17:59 -0700 Received: from DE02WEMBXB.internal.synopsys.com ([fe80::95ce:118a:8321:a099]) by DE02WEHTCA.internal.synopsys.com ([::1]) with mapi id 14.03.0266.001; Thu, 3 Nov 2016 17:17:57 +0100 From: Alexey Brodkin To: "netdev@vger.kernel.org" CC: "manabian@gmail.com" , "linux-kernel@vger.kernel.org" , "peppe.cavallaro@st.com" , "fabrice.gasnier@st.com" , "linux-snps-arc@lists.infradead.org" , "alexandre.torgue@gmail.com" , "preid@electromag.com.au" , "davem@davemloft.net" Subject: stmmac: GMAC_RGSMIIIS reports bogus values Thread-Topic: stmmac: GMAC_RGSMIIIS reports bogus values Thread-Index: AQHSNe3WHCWZ99cl6060z9b7QcHLUw== Date: Thu, 3 Nov 2016 16:17:56 +0000 Message-ID: <1478189833.4072.65.camel@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.14.110] Content-ID: <5EBE6F8D4D6A53449DBD21CCE54E620C@internal.synopsys.com> MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello, I'm seeing pretty strange issue with GMAC reporting a lot of link state changes based on bits in GMAC_RGSMIIIS. It looks like that: -------------------------->8----------------------- Link is Down Link is Up - 10/Full Link is Down Link is Up - 10/Half Link is Down Link is Down Link is Up - 10/Half Link is Up - 1000/Half Link is Down Link is Down Link is Down Link is Down Link is Up - 10/Half Link is Down Link is Down Link is Up - 1000/Half Link is Up - 1000/Full -------------------------->8----------------------- What's especially interesting my board with GMAC is connected to 100Mbit device which means there's no chance for 1Gb mode to be set. Also this has nothing to do with link state detected and reported by PHY via MDIO. So obviously GMAC_RGSMIIIS bits are wrong. But given the fact that GMAC_RGSMIIIS bits are set based on state of RXD[3:0] lines of RGMII I may only thing that it's PHY (in my case DP83865) who's sending random data on the RXD during inter-frame gap. Note data transferred through that networking connection is perfectly correct and actually I haven't see those link state prints before kernel v4.8 basically because the prints in question were implemented with pr_debug() and then with [1] we got pr_info() that made prints visible by default. Since I don't have any means to capture all required GMII signals to do better analysis and my data is not corrupted in the end I'm thinking about way how to mute these pretty senseless messages. One thing I may think of we may disable checking of GMAC_RGSMIIIS if a particular board uses MDIO for PHY setup. Something like that: -------------------------->8----------------------- -------------------------->8----------------------- Any thoughts on that are much appreciated! Regards, Alexey [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70523e639bf8ca09b3357371c3546cee55c06351 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c @@ -337,7 +337,7 @@ static int dwmac1000_irq_status(struct mac_device_info *hw,           dwmac_pcs_isr(ioaddr, GMAC_PCS_BASE, intr_status, x);   -       if (intr_status & PCS_RGSMIIIS_IRQ) +       if (!priv->use_mdio && (intr_status & PCS_RGSMIIIS_IRQ))                 dwmac1000_rgsmii(ioaddr, x);           return ret; diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 6c85b61aaa0b..34e9de0450ba 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3356,11 +3356,13 @@ int stmmac_dvr_probe(struct device *device,           stmmac_check_pcs_mode(priv);   +       priv->use_mdio = 0;         if (priv->hw->pcs != STMMAC_PCS_RGMII  &&             priv->hw->pcs != STMMAC_PCS_TBI &&             priv->hw->pcs != STMMAC_PCS_RTBI) {                 /* MDIO bus Registration */                 ret = stmmac_mdio_register(ndev); +               priv->use_mdio = 1;                 if (ret < 0) {                         pr_debug("%s: MDIO bus (id: %d) registration failed",                                  __func__, priv->plat->bus_id);