From patchwork Thu Dec 7 14:27:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 120989 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp8426589qgn; Thu, 7 Dec 2017 06:29:06 -0800 (PST) X-Google-Smtp-Source: AGs4zMb1Srh4JN/fxNh+l6OZJmJKLwsr0z4BLs7THzY5T18sNZfTmfBXVixfQr+1bmPzLZYhSupX X-Received: by 10.159.249.75 with SMTP id h11mr4168723pls.223.1512656946413; Thu, 07 Dec 2017 06:29:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512656946; cv=none; d=google.com; s=arc-20160816; b=vlyZJrFieRxE3rN7ajKzG0egfWQaqrCcVC2gKqDId6ezFKlPa+SvdJlkgGgg7gjK/1 fow5VhinPTFZbSTJbptq3jSGkJFp9c+2UbipMecnyOQ4yL+78KEMwlNwHcGfYj8Wg5Ki iSuYsChrtRForJ5RotUNtO1Sm0HYFUQiJBasfuUEyzJnu8ZItwuBJiB/vEtyblC3+A4+ VDjR2M49Vw6rzEvwDVeBd8MmY1m9Rd9rQ5SZzSyljkZSUCVLWzZg3pgRzaUS471rSxk5 kHH910XEW3jvidTDr9MVWBV+0I5WCaY6K5VTIzgE2TS6QGdf+A1Dj9u5MiKf+0fQaTi6 EHrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=3UvWykb2FP/peh9qpSptmY33mHqvfp6epBds5Tj7ys0=; b=s0HwTMrFDd5R/mrhFv3h3IOFDUiKx4Zf2WHCqlFbpuWUaMCeL5E8L0wEx9mRc0ArJM 0lGx4viQmKcS8Z3ban0LaIcEms2v87/b1MyzSuyHTZb21VzHmErLrzHgA7MZ96MmsBzn EuxDP8gauh4yj5raDN/bQ0GzpT96WHgnGkmhAmRPP80tazOyyIgclINi5m7vAeDRXGZ2 eDrSLCa5zONKcaUoiFNKIKDzwdv3wUS5ODq7yd7E9izMw81VzP3Sbv9f+XR+IBSVYVLG 4tiTZEiF1gAoVP+zfqLa6QGLp592ziEac0fKWHqbStZf2FyG0qatZmSW9SbDqw5ffVbW BvCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=I0vGMvU1; 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 26si4141119pfo.269.2017.12.07.06.29.05; Thu, 07 Dec 2017 06:29:06 -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=I0vGMvU1; 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 S1754060AbdLGO3E (ORCPT + 22 others); Thu, 7 Dec 2017 09:29:04 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:34528 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753818AbdLGO1Y (ORCPT ); Thu, 7 Dec 2017 09:27:24 -0500 Received: by mail-wm0-f53.google.com with SMTP id y82so879646wmg.1 for ; Thu, 07 Dec 2017 06:27:23 -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:in-reply-to:references; bh=3UvWykb2FP/peh9qpSptmY33mHqvfp6epBds5Tj7ys0=; b=I0vGMvU1t7Nn4gBUTW+g7CAzedHuwBRgusg/VYotfFt/ggHUEo47dXOS4iwu90Nj/Z NHEssRJB68aFTf0+8L58DOuM2zifuH8zFY1u/y+kTxza82rzCKvexbqEiFFneSbh2Fss cgLr8k2bvLfjWJ7atx2hqlYOUOr+ryEljhpEM0hlZUWY2CUtPK9wHR5XojgG19IeJTTT /aSYRTlB/ly2IJl36dvwddFrM/QnTPpwKLc2SUwcwVNTXBhMDC4lapTPzzG7lwfe4rIW 51SnAAamO6xD0BEpriRNf0XpxK4IPY8hBuHqSVuNC6M+A+cP5ScZfhG40DBY6ps7/MG1 u2WA== 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:in-reply-to :references; bh=3UvWykb2FP/peh9qpSptmY33mHqvfp6epBds5Tj7ys0=; b=iMcbnCMHW4+HzMDAo9s6I1qaP3lwt0sY2hPW/kAYHAO/tvwKOfPmrO8IYw/xff0n0d l0QELJ5wJyRzLIJDX3BrVTTEV/AmcLIX4r/GXripMvBshaj8tocS9/EzpNs35kVF32DE JmnqITMF0iwn9BTbimUP/z/ogyi95P62lHfC1m8zDi+tU3v9RglxFqmIOpwgiwve/FUq HdY0iyj5kIKPmdMMi9q8tYLCeSip3TEx1hc0Iv3nd8YGc6LfaYMwy/c6U8zCigaAV8Lc n2JiVMx7ctYJ1e6NKhk+H4XfzaT2r/PMIQpwapE7CgVpKt2fAVeNSyWf8skPWLlBXrQs BJSQ== X-Gm-Message-State: AKGB3mIDw3mWndW5AsrDVl8WD6uEnpkAQtMJkG8xj9LXZHA2ahOAjgRT 4JWQiiMdNvxJo+41KOlaUv9DXA== X-Received: by 10.28.26.139 with SMTP id a133mr1314607wma.90.1512656843152; Thu, 07 Dec 2017 06:27:23 -0800 (PST) Received: from boomer.baylibre.local ([90.63.244.31]) by smtp.googlemail.com with ESMTPSA id t138sm6264520wme.16.2017.12.07.06.27.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Dec 2017 06:27:22 -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-next v2 5/8] net: phy: meson-gxl: detect LPA corruption Date: Thu, 7 Dec 2017 15:27:12 +0100 Message-Id: <20171207142715.32578-6-jbrunet@baylibre.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171207142715.32578-1-jbrunet@baylibre.com> References: <20171207142715.32578-1-jbrunet@baylibre.com> 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 this differently, feel free to let me know. drivers/net/phy/meson-gxl.c | 59 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 58 insertions(+), 1 deletion(-) -- 2.14.3 diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c index 2e8c40df33c2..726e0eeed475 100644 --- a/drivers/net/phy/meson-gxl.c +++ b/drivers/net/phy/meson-gxl.c @@ -35,11 +35,16 @@ #define TSTWRITE 23 #define BANK_ANALOG_DSP 0 +#define BANK_WOL 1 #define BANK_BIST 3 /* Analog/DSP Registers */ #define A6_CONFIG_REG 0x17 +/* WOL Registers */ +#define LPI_STATUS 0xc +#define LPI_STATUS_RSV12 BIT(12) + /* BIST Registers */ #define FR_PLL_CONTROL 0x1b #define FR_PLL_DIV0 0x1c @@ -145,6 +150,58 @@ static int meson_gxl_config_init(struct phy_device *phydev) return genphy_config_init(phydev); } +/* This specific 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; + + /* Aneg is done, let's check everything is fine */ + wol = meson_gxl_read_reg(phydev, BANK_WOL, LPI_STATUS); + 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 & LPI_STATUS_RSV12) || + ((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, @@ -155,7 +212,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, },