Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp457823ybi; Fri, 26 Jul 2019 12:41:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJZZThamVxSfhTwikWhiqZ6clFXYqqQcem48PeplVY6Od/k8PACpF+sF7ofLOGWUceDGI6 X-Received: by 2002:a17:90a:d996:: with SMTP id d22mr99825200pjv.86.1564170108074; Fri, 26 Jul 2019 12:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564170108; cv=none; d=google.com; s=arc-20160816; b=qkXnSxten2vVBFSRYfaJSZeAo1MsFW4GP6nXYV4aN5/C3LLc8At3ZHEk+tEakOzFMl Kl1aJ0MBkuxkbi86IZ8WXU92aNiE/n9Dmpy3HtGBeNIYjdSLTiZH40Bm/ZRnP/3VdNGe TT9SNYcCTOXTeuEEdxe6xOBRStSycsC8h+iuZorqW6ZQVEKee4/zCpu2NRt7Yh+1LCvN 37r5EZ33hXvyIAeU564TpqAiclbrI5dMAuFVfqqTgbx7TxwZ4OeSYvxsxp27sCVJLalM r7xPSnDS44+sJfeXh3sbs4CtVOxkb8NrgPDAj3tuapdUGyD0HohwBLOPRcZ1wf0TtWxo P5rg== 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:dkim-signature; bh=JKw39pI2llb7A01NXuEKDfaC4+iRUymYwQL0imdPSKs=; b=BTd4bEP5rODCVrsR73XFxVVYTHABUSooH3K/hu8jT1GN3DrmGEIcCMgSC7cLexxGg4 44hNohFqbNdRYmWK7a9S6IT0Mf1Lmp+J91MFmSFtugyjL6euBjDWAANddrCJqqjVHWVa TActarQ1rEw4sE2+ZpYuIgxiFrM1R5s/4trDqFb+ll5umdJrJjlj1cxTtj3OGh38WxT5 dgPyhWrBsSxy1Zeow0fuJZyiNwHV89to0QvQ9SJQT9FPl6VUBChzz07sh7g7L10fko5/ yEgb/KG45cnnDA66oIC/eSLgtbdLShImeuEL9fbd7aP3HNoK3LRM/lCf8PlCE0b4nMKf McmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dNqzYdVq; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5si17760505pls.358.2019.07.26.12.41.33; Fri, 26 Jul 2019 12:41:48 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dNqzYdVq; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728655AbfGZSPC (ORCPT + 99 others); Fri, 26 Jul 2019 14:15:02 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:37381 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726781AbfGZSPC (ORCPT ); Fri, 26 Jul 2019 14:15:02 -0400 Received: by mail-wm1-f67.google.com with SMTP id f17so48395842wme.2; Fri, 26 Jul 2019 11:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JKw39pI2llb7A01NXuEKDfaC4+iRUymYwQL0imdPSKs=; b=dNqzYdVqcZfPAziZ23MpFrZNMRjes+fGTgZkSQ1C+5pbkn7xHFhvm8aXQ1gHZJW9ZH El2HrLr604GsqqIFQg5uuc+Zg0CY4Ust2WMYx5pWJnVbQFNF9lbeDcv6H/gu5PRS3x8B nBp3Aut03vN4wALa1S8wR/68wgUpJxD8UlMbQdqpvaj1ca03j5ULZ+UB5HD6pmjTQjzR gg/ttUspqIuZ9YJdsrWGXq0oolILm02GG1l9aflkLD+c/+MOup7a5dV9pNvTTCSTp8uD qs/fL5gzo4gnV+OBdwvaDSLxDtbf6s7lprq1Q9wPXS6IT8NucSkx2or0ekft2KeT1Ahm zlXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JKw39pI2llb7A01NXuEKDfaC4+iRUymYwQL0imdPSKs=; b=ffhg1Hl2sxi1CDhgpLTgrdvghFHnLaONSZcBb1+Ps/f57AsTJrXluGijcE+CQ3W2ic cgCFMzZlIoHWIFYigmI8r2FnpFAO/lKnqFpeFAYAGdIBJUHjxm7FszaVBM9mhNECD/8Z P67odqxA6iCVoodR0jFMnCdduyEYom3nvxgscwxg+yUX55r9JZESx9XCOOdkrCpQm+oY PQGeYR5MIr02QG7uapWLDw3FIfr5PzEpzSJSe3QeCg9zDC+fuq5/gDcZhnmEXV+3GmV/ m/OLxDLec0VaKYvj88nzPXDG0lcr7jnbZLxNk45DFsa9cTQGo9meFcOBc0QzS7xyFSlr XFtQ== X-Gm-Message-State: APjAAAWlGmE5LZGSSXreYO7Se0eZnOXInJql37hrIjcsZjc7EU9uQ2Nt 0EPw173Ts8rD3Vis0yk0fCM= X-Received: by 2002:a05:600c:230c:: with SMTP id 12mr83673655wmo.166.1564164899711; Fri, 26 Jul 2019 11:14:59 -0700 (PDT) Received: from ?IPv6:2003:ea:8f43:4200:55f1:e404:698f:358? (p200300EA8F43420055F1E404698F0358.dip0.t-ipconnect.de. [2003:ea:8f43:4200:55f1:e404:698f:358]) by smtp.googlemail.com with ESMTPSA id u6sm54367668wml.9.2019.07.26.11.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2019 11:14:59 -0700 (PDT) Subject: Re: [RFC] net: phy: read link status twice when phy_check_link_status() To: Yonglong Liu , andrew@lunn.ch, davem@davemloft.net Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linuxarm@huawei.com, salil.mehta@huawei.com, yisen.zhuang@huawei.com, shiju.jose@huawei.com References: <1564134831-24962-1-git-send-email-liuyonglong@huawei.com> From: Heiner Kallweit Message-ID: <92f42ee8-3659-87a7-ac96-d312a98046ba@gmail.com> Date: Fri, 26 Jul 2019 20:14:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1564134831-24962-1-git-send-email-liuyonglong@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26.07.2019 11:53, Yonglong Liu wrote: > According to the datasheet of Marvell phy and Realtek phy, the > copper link status should read twice, or it may get a fake link > up status, and cause up->down->up at the first time when link up. > This happens more oftem at Realtek phy. > This is not correct, there is no fake link up status. Read the comment in genphy_update_link, only link-down events are latched. Means if the first read returns link up, then there is no need for a second read. And in polling mode we don't do a second read because we want to detect also short link drops. It would be helpful if you could describe your actual problem and whether you use polling or interrupt mode. > I add a fake status read, and can solve this problem. > > I also see that in genphy_update_link(), had delete the fake > read in polling mode, so I don't know whether my solution is > correct. > > Or provide a phydev->drv->read_status functions for the phy I > used is more acceptable? > > Signed-off-by: Yonglong Liu > --- > drivers/net/phy/phy.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > index ef7aa73..0c03edc 100644 > --- a/drivers/net/phy/phy.c > +++ b/drivers/net/phy/phy.c > @@ -1,4 +1,7 @@ > // SPDX-License-Identifier: GPL-2.0+ > + err = phy_read_status(phydev); > + if (err) > + return err; This seems to be completely wrong at that place. > /* Framework for configuring and reading PHY devices > * Based on code in sungem_phy.c and gianfar_phy.c > * > @@ -525,6 +528,11 @@ static int phy_check_link_status(struct phy_device *phydev) > > WARN_ON(!mutex_is_locked(&phydev->lock)); > > + /* Do a fake read */ > + err = phy_read(phydev, MII_BMSR); > + if (err < 0) > + return err; > + > err = phy_read_status(phydev); > if (err) > return err; >