Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5790872pxb; Wed, 26 Jan 2022 22:32:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJykkvpqSxFnNUeYYUMaLe3E9vd4eNwZ9wdrW4/HG0wCIODd+1oBQWiRDousXavhMvbjyJIy X-Received: by 2002:a17:906:1e0e:: with SMTP id g14mr1799147ejj.363.1643265151930; Wed, 26 Jan 2022 22:32:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643265151; cv=none; d=google.com; s=arc-20160816; b=WZL83EPtIy5Q/rOLsqYucxWnqxkTBcAalWX2jEMW8Lu846JOB31/OLYYOeM3YBaSel 31I4fY19a6dL27N68yxYMptOPbH7kWq/Luj5AHah6dHQiecxHUQokmnvtu4JGa4TaIea VC0ftaC0JJn8Cg92zs27MlFvKMkg5BGbEuIqHew5SudaAeXQISvoSpr76WfMk8a71KzX 6euLNkRfYYEuXVrbzvPSHkI++YH2nBWWkbh8ily8rtSEePXo3nCZ2dD9+yl9LPVxjp0D 0ANwPFwym/41ybSUJsoLTD6DlmTP8kCwErfApaY+/lPFJyPmcIlp8DIsQngjjuthuAh0 MewQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KtETfU1+wqNMppMn4Ma2jeShcVH64evaxx2kWzZVGG8=; b=JsLPUpLy9U9P9CVw2e1xJVxjgyaBRYgAk6o5FwogGfIVMcrGFuk82agTBzV1k8Gn80 rja9bHXO8syV9EB5kxNTkqSYxYk1u4jhaab+Aw3Zha86S+YAa/0n7TiniWu2enQHk4SA pxVWsoTDbESkdeRpeUKjVZ6ootfswp0kmX2lhA9xTSlTPKyUKsrdnTGPTObe2hNgtWML nSdrAOiger4v1dvtNroc60VadtEMW20T8qzyeZCsYgRGUHMj4XyoEGv3pWMbqBDyo4GP K69Aw7cEIjS/FSAd/n5vIyLEI3T3MeQY6hFabBbPlX3jxSrAwvwS7dvNksqQ2zKtfjlH LMgA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=GUCG7xO1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i6si1100783edc.398.2022.01.26.22.32.07; Wed, 26 Jan 2022 22:32:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=GUCG7xO1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230354AbiAZXp0 (ORCPT + 99 others); Wed, 26 Jan 2022 18:45:26 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:56538 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbiAZXpT (ORCPT ); Wed, 26 Jan 2022 18:45:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=KtETfU1+wqNMppMn4Ma2jeShcVH64evaxx2kWzZVGG8=; b=GUCG7xO1z7VQ6MisHEWzT+utQp +DXEPSm1F4TbRCBm2yeQVrAIxBghnENx689AWvbxjbF1eMG6OcFzPZd298SnTDAdWavU4iLSQgZ1v V7DHmd8R+cpZAs7mEIOO7ZC5JuPH2Q5lmby54uPTLzMMUDXXn5BzSxYHqDgps4V9LTRI=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nCryS-002sOg-8K; Thu, 27 Jan 2022 00:45:12 +0100 Date: Thu, 27 Jan 2022 00:45:12 +0100 From: Andrew Lunn To: Tobias Waldekranz Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Vivien Didelot , Florian Fainelli , Vladimir Oltean , linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Improve performance of busy bit polling Message-ID: References: <20220126231239.1443128-1-tobias@waldekranz.com> <20220126231239.1443128-2-tobias@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126231239.1443128-2-tobias@waldekranz.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > @@ -86,12 +86,12 @@ int mv88e6xxx_write(struct mv88e6xxx_chip *chip, int addr, int reg, u16 val) > int mv88e6xxx_wait_mask(struct mv88e6xxx_chip *chip, int addr, int reg, > u16 mask, u16 val) > { > + const unsigned long timeout = jiffies + msecs_to_jiffies(50); > u16 data; > int err; > - int i; > > /* There's no bus specific operation to wait for a mask */ > - for (i = 0; i < 16; i++) { > + do { > err = mv88e6xxx_read(chip, addr, reg, &data); > if (err) > return err; > @@ -99,8 +99,8 @@ int mv88e6xxx_wait_mask(struct mv88e6xxx_chip *chip, int addr, int reg, > if ((data & mask) == val) > return 0; > > - usleep_range(1000, 2000); > - } > + cpu_relax(); > + } while (time_before(jiffies, timeout)); I don't know if this is an issue or not... There are a few bit-banging systems out there. For those, i wonder if 50ms is too short? With the old code, they had 16 chances, no matter how slow they were. With the new code, if they take 50ms for one transaction, they don't get a second chance. But if they have taken 50ms, around 37ms has been spent with the preamble, start, op, phy address, and register address. I assume at that point the switch actually looks at the register, and given your timings, it really should be ready, so a second loop is probably not required? O.K, so this seems safe. Andrew