Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2983818ybb; Sun, 22 Mar 2020 12:20:24 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsNHdU68yLm9QL+Vf+CW0he5JxAcfWD0EP0CZbUGP99NyD6P+OeR9rZVB6IXO4By2HLoXd0 X-Received: by 2002:aca:4fcc:: with SMTP id d195mr15363792oib.99.1584904824472; Sun, 22 Mar 2020 12:20:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584904824; cv=none; d=google.com; s=arc-20160816; b=PEENhk/9TJ2UqpZQabNWJvNd5GEMpB3Hg9A5gMyOwXm0Y6h0CVsu/jZ/urKUeCuz2N RRBiAN/bjC9D6vGgapY2BrjzhbvF4taxuCEwRyVgx0qUJ5EnecN90qGpL51I6oV0Bw/U mqsT5VaHU+ugA3lQ94HPWTJSipSZBy/DIA6DnkPd+8xOn69v+XLr4WXJuycVTY77jF5U zV1veYpwxiU9CJopsf142YDisaeOa9nXSje2jo5RAljLwW281KgkujVT/GxXMSehTmgr sr3ApY7nh/IspfWfuBFHeTm0RpDmEU4k3IV0VxWY1GjfnBNaMQuXUzE/TkaZiQmkdIA2 tm0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=RIAHvjZgxomQVpQmFNUiVpDvO2IIucaa9jhgrsz8pG4=; b=ylynAVtTk5UEknkeq9ayPIWnx2FwK9aR/Y9HOpTZBGVjRRfBeN5xt8oJverEX69+gi lIUzNGoyoy0df58sePsGLVS0fdRAZxeyxgKwDaVe4YIOG7HFeWI17KLvzCKmEa9MWE/+ LYeSZeXeZx6K3fehyL/DtVdNvzNcuz3aBJHtZSBYe7IXsOJrkXZmgQsC4rVuy+zUoMZR a8BDcBHwObtb9P8J1jL3jgDoeQbXbfnkahd/1muurNTk5/Wb50h2hz+tHB1FI5uc5Nvm HSIOFpJRxeGHSThZxQknNDtid9z0+xraAPYCf4HwnWiAyVryH2Nu2e2xYRZVmQ0QjwVD i10w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b="saMGtVA/"; 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=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p15si1199621otk.63.2020.03.22.12.20.08; Sun, 22 Mar 2020 12:20:24 -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=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b="saMGtVA/"; 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=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726756AbgCVTSy (ORCPT + 99 others); Sun, 22 Mar 2020 15:18:54 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:40278 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725997AbgCVTSy (ORCPT ); Sun, 22 Mar 2020 15:18:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RIAHvjZgxomQVpQmFNUiVpDvO2IIucaa9jhgrsz8pG4=; b=saMGtVA/YKdtAqF7xH6b7rV0u l7FOMTkOsflESbP4bX4ej2nf+wfqjZGyiGYiIVL6d3pXfZLLcnmojQS1QcLWE5iTGK3pvVRMiRd3L dOBa+fxaWc4tyC7gShu+LORrP04YDnaOKsyjFZ6ZRxEAwbpMD+lxLZthMc7MbAt7Nx4DPBt5e9VRx SQhQlrBjLA7huji+msBOUFlvnRKGRXe58xfBzmYqGaIwuBp6KpGOE8/f6Tg/RvoCE7PgUyETbztli 2VNWtXvD9g8IJUNyUlXYnfNVR960sgEAfkx1QGoSyIPoqJdolWa7QrI49fBFvXLWSf2CxSrTVtAQK HN2SXpfgw==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:35850) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jG67I-0005AM-5m; Sun, 22 Mar 2020 19:18:36 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jG67E-0007yZ-4A; Sun, 22 Mar 2020 19:18:32 +0000 Date: Sun, 22 Mar 2020 19:18:32 +0000 From: Russell King - ARM Linux admin To: Dejin Zheng Cc: andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com, davem@davemloft.net, mchehab+samsung@kernel.org, corbet@lwn.net, gregkh@linuxfoundation.org, broonie@kernel.org, tglx@linutronix.de, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v5 08/10] net: phy: use phy_read_poll_timeout() to simplify the code Message-ID: <20200322191832.GW25745@shell.armlinux.org.uk> References: <20200322174943.26332-1-zhengdejin5@gmail.com> <20200322174943.26332-9-zhengdejin5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200322174943.26332-9-zhengdejin5@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 23, 2020 at 01:49:41AM +0800, Dejin Zheng wrote: > use phy_read_poll_timeout() to replace the poll codes for > simplify the code in phy_poll_reset() function. > > Signed-off-by: Dejin Zheng > --- > v4 -> v5: > - it can add msleep before call phy_read_poll_timeout() > to keep the code more similar. so add it. > v3 -> v4: > - drop it. > v2 -> v3: > - adapt to it after modifying the parameter order of the > newly added function > v1 -> v2: > - remove the handle of phy_read()'s return error. > > > drivers/net/phy/phy_device.c | 17 +++++------------ > 1 file changed, 5 insertions(+), 12 deletions(-) > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c > index a585faf8b844..24297ee7f626 100644 > --- a/drivers/net/phy/phy_device.c > +++ b/drivers/net/phy/phy_device.c > @@ -1059,23 +1059,16 @@ EXPORT_SYMBOL(phy_disconnect); > static int phy_poll_reset(struct phy_device *phydev) > { > /* Poll until the reset bit clears (50ms per retry == 0.6 sec) */ > - unsigned int retries = 12; > - int ret; > - > - do { > - msleep(50); > - ret = phy_read(phydev, MII_BMCR); > - if (ret < 0) > - return ret; > - } while (ret & BMCR_RESET && --retries); > - if (ret & BMCR_RESET) > - return -ETIMEDOUT; > + int ret, val; > > + msleep(50); > + ret = phy_read_poll_timeout(phydev, MII_BMCR, val, !(val & BMCR_RESET), > + 50000, 550000); > /* Some chips (smsc911x) may still need up to another 1ms after the > * BMCR_RESET bit is cleared before they are usable. > */ > msleep(1); > - return 0; > + return ret; This isn't actually equivaent behaviour. If the read timed out, the old code didn't wait 1ms. Your new code does. However, since we've waited about 600ms already, it probably doesn't matter. These sorts of things should be documented in the commit log, IMHO, so it's obvious that it's been considered. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up