From patchwork Fri Dec 8 11:08:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 121146 Delivered-To: patch@linaro.org Received: by 10.80.152.193 with SMTP id j59csp434866edb; Fri, 8 Dec 2017 03:08:34 -0800 (PST) X-Google-Smtp-Source: AGs4zMaTEhMk5KW+W0R4R6/L8Dn8mNMEmCmBQ+WXi/Q10ynPbWSttgfpCylsIzp9xztQlr65oMVL X-Received: by 10.101.75.142 with SMTP id t14mr29232894pgq.122.1512731314677; Fri, 08 Dec 2017 03:08:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512731314; cv=none; d=google.com; s=arc-20160816; b=bnc9CjYxFuXMs7CvRJdjau0Xt6KBdljBl7oDYoOz7964iqCSoddY62OSF08AolZ6EP 7Zhyn3+THPm6jCb1pj3nj1sstRdDzU2n0bBLbcXLAvOcRQHP8C/+Eh2hcVUGX2OtBdfa cZM0AxzqUAYjn/Rx1S6ivYb5WtXLcBWGrQ1I5k0dOT6to+w9nvcnQ5oI1q32MkQpkqSZ LO2EunKsgUi5AQws1UTJsQxpx2YhYmJIAtABuYSb2BLq2IcAZxqT8kbvxcw28RZocBF4 NOUXor8Ody1vgykYg4C756HskxGMkoGu3uetOqx6BKIykc46MNsNAJTBzFTk+jElqQRJ RpNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=WNuQZ32N5f0xtqUmmNLi8+lIrAawdc/4v90ElwSGS/A=; b=snMsNTTA/efcfwWHBwczL8QeG2wMJiq9qKOx1Pqu+q3biWsTaYeTrk0hh8Ife/uDEE GASDIRY9lSgEJCBotbOPJLMa7EMHCuJBdO5euNVsKPYDS4scuXy5V9Xr3mNURwYYuEPk +R1VHwVgbLdOSQaxyYmhvEi61XVzC4Ze6EKsKwamfFFycx7PoTxh2necMNvRfVx1HaXH mPpg8MU9+wmRpllUsKkcxO8xMQ5sqyDeWT2nY085hV6T5Qf5bSgLe9N57Vp2ww4ONp8f w2cIjh0ezT0hHn9dtzOxCNlxupLbp1XKFZ+0DV+U2/nn1dQONJxqKQpUce4KiW24abNr l3rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=d7TYE/gD; 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 s59si5394537plb.276.2017.12.08.03.08.34; Fri, 08 Dec 2017 03:08:34 -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; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=d7TYE/gD; 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 S1753630AbdLHLIa (ORCPT + 12 others); Fri, 8 Dec 2017 06:08:30 -0500 Received: from mail-wr0-f172.google.com ([209.85.128.172]:33950 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753279AbdLHLIX (ORCPT ); Fri, 8 Dec 2017 06:08:23 -0500 Received: by mail-wr0-f172.google.com with SMTP id y21so10469959wrc.1 for ; Fri, 08 Dec 2017 03:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=WNuQZ32N5f0xtqUmmNLi8+lIrAawdc/4v90ElwSGS/A=; b=d7TYE/gDSwf42cs3QJZAkVZx1Gg3b53cqFPx7RC9MmLSIbv41t/24mC7wwhObLEovg zOb7apomzRH3Fi5vGruAfzunIjQtLdj/VK3Tj/t8Cz+2/jT4vf06Ckpw+JC8+y4o41nb dKoUx+BO7WwbHxS4lBNo3bcfl7QdGG5NA7Z2AvYKN7oY4umu3OsbW1mcEXJKQtdSmLFd V3sdB1ErSaZXdKH6rLOMO7VOl1dV6B7FuRZN4lt5xhrSVus8sofRyjfCJSqshhSfttr+ Cb/fMbvlDOcfoe5gvvbHOxJxvr6IwFSrp6r2rMwMk01ZQogWcx4Qf49AIhfUs+RMiI4W gGWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=WNuQZ32N5f0xtqUmmNLi8+lIrAawdc/4v90ElwSGS/A=; b=k++bnRn4At00fFesnsYt76EyaPknJCbDty5JB72BDN6ZB7RsRvlyHj7DbjwQ9oKnBa +lpFFhijCy5gawdv1K3inUjKhjNcK5nquox0rZtotlGDNO6pxn26H09Sf1hbCnqxHIGZ LUyf8sEd2pEmGW+vr8raVNWZ1iI1bIykFBGU/fAKC+b6LQPbuZR12LRYowFlJT/klSzM 4kJvXmzgp+wVX5Sf4BS9b1c3zitxiz75PpSzYALMy63XAVzDvNPiPwOkyEbAGipguHxn wYxB920T42hfXoB5KSBPg4yylEk/t4FjCQAInK8pNYyEglzRzM6liXtcjQ2MZuFch6IK DQRQ== X-Gm-Message-State: AJaThX6YGfMGQROsEpsOaCiiaWNme7UUVr2HA1rLtVAlPSuJRMcA4xiq sjAmeqv4Cka/6x51goLC6ndClQ== X-Received: by 10.223.184.173 with SMTP id i42mr28003573wrf.31.1512731301876; Fri, 08 Dec 2017 03:08:21 -0800 (PST) Received: from boomer.baylibre.local ([90.63.244.31]) by smtp.googlemail.com with ESMTPSA id q15sm8091009wra.91.2017.12.08.03.08.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Dec 2017 03:08:21 -0800 (PST) From: Jerome Brunet To: Andrew Lunn , Florian Fainelli Cc: Jerome Brunet , Kevin Hilman , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH net v3] net: phy: meson-gxl: detect LPA corruption Date: Fri, 8 Dec 2017 12:08:11 +0100 Message-Id: <20171208110811.30789-1-jbrunet@baylibre.com> X-Mailer: git-send-email 2.14.3 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The purpose of this change is to fix the incorrect detection of the link partner (LP) advertised capabilities which sometimes happens with this PHY (roughly 1 time in a dozen) This issue may cause the link to be negotiated at 10Mbps/Full or 10Mbps/Half when 100MBps/Full is actually possible. In some case, the link is even completely broken and no communication is possible. To detect the corruption, we must look for a magic undocumented bit in the WOL bank (hint given by the SoC vendor kernel) but this is not enough to cover all cases. We also have to look at the LPA ack. If the LP supports Aneg but did not ack our base code when aneg is completed, we assume something went wrong. The detection of a corrupted LPA triggers a restart of the aneg process. This solves the problem but may take up to 6 retries to complete. Fixes: 7334b3e47aee ("net: phy: Add Meson GXL Internal PHY driver") Signed-off-by: Jerome Brunet --- I suppose this patch probably seems a bit hacky, especially the part about the link partner acknowledge. I'm trying to figure out if the value in MII_LPA makes sense but I don't have such a deep knowledge of the ethernet spec. To me, it does not makes sense for the LP to support ANEG (Bit 1 in MII_EXPENSION), the aneg to have successfully complete and, at the same time, LP does not ACK our base code word, which we should have sent during this aneg. If you think this may have unintended consequences or if you have an idea to do this differently, feel free to let me know. This fix has been tested on the libretech-cc and khadas VIM The v2 [0] had dependencies on other changes which were not fixes. This v3 is re-implementation of v2 without the dependencies to be merged as a fix and easily backportable. All the ugly phy_write() with hexadecimal values will go away when then clean-up gets through. [0]: https://lkml.kernel.org/r/20171207142715.32578-6-jbrunet@baylibre.com drivers/net/phy/meson-gxl.c | 74 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 73 insertions(+), 1 deletion(-) -- 2.14.3 diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c index 1ea69b7585d9..700007dd4be5 100644 --- a/drivers/net/phy/meson-gxl.c +++ b/drivers/net/phy/meson-gxl.c @@ -22,6 +22,7 @@ #include #include #include +#include static int meson_gxl_config_init(struct phy_device *phydev) { @@ -50,6 +51,77 @@ static int meson_gxl_config_init(struct phy_device *phydev) return 0; } +/* This function is provided to cope with the possible failures of this phy + * during aneg process. When aneg fails, the PHY reports that aneg is done + * but the value found in MII_LPA is wrong: + * - Early failures: MII_LPA is just 0x0001. if MII_EXPANSION reports that + * the link partner (LP) supports aneg but the LP never acked our base + * code word, it is likely that we never sent it to begin with. + * - Late failures: MII_LPA is filled with a value which seems to make sense + * but it actually is not what the LP is advertising. It seems that we + * can detect this using a magic bit in the WOL bank (reg 12 - bit 12). + * If this particular bit is not set when aneg is reported being done, + * it means MII_LPA is likely to be wrong. + * + * In both case, forcing a restart of the aneg process solve the problem. + * When this failure happens, the first retry is usually successful but, + * in some cases, it may take up to 6 retries to get a decent result + */ +int meson_gxl_read_status(struct phy_device *phydev) +{ + int ret, wol, lpa, exp; + + if (phydev->autoneg == AUTONEG_ENABLE) { + ret = genphy_aneg_done(phydev); + if (ret < 0) + return ret; + else if (!ret) + goto read_status_continue; + + /* Need to access WOL bank, make sure the access is open */ + ret = phy_write(phydev, 0x14, 0x0000); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x0400); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x0000); + if (ret) + return ret; + ret = phy_write(phydev, 0x14, 0x0400); + if (ret) + return ret; + + /* Request LPI_STATUS WOL register */ + ret = phy_write(phydev, 0x14, 0x8D80); + if (ret) + return ret; + + /* Read LPI_STATUS value */ + wol = phy_read(phydev, 0x15); + if (wol < 0) + return wol; + + lpa = phy_read(phydev, MII_LPA); + if (lpa < 0) + return lpa; + + exp = phy_read(phydev, MII_EXPANSION); + if (exp < 0) + return exp; + + if (!(wol & BIT(12)) || + ((exp & EXPANSION_NWAY) && !(lpa & LPA_LPACK))) { + /* Looks like aneg failed after all */ + phydev_dbg(phydev, "LPA corruption - aneg restart\n"); + return genphy_restart_aneg(phydev); + } + } + +read_status_continue: + return genphy_read_status(phydev); +} + static struct phy_driver meson_gxl_phy[] = { { .phy_id = 0x01814400, @@ -60,7 +132,7 @@ static struct phy_driver meson_gxl_phy[] = { .config_init = meson_gxl_config_init, .config_aneg = genphy_config_aneg, .aneg_done = genphy_aneg_done, - .read_status = genphy_read_status, + .read_status = meson_gxl_read_status, .suspend = genphy_suspend, .resume = genphy_resume, },