Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5791347pxb; Wed, 26 Jan 2022 22:33:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJxxpm72/+e67Jl4YaHs4KyuTW41wJnda+Jm/ZTJWh2x6W0qKBy/KHjk3Ih4/CG2prVUVnqL X-Received: by 2002:a17:906:1e0e:: with SMTP id g14mr1801559ejj.363.1643265213466; Wed, 26 Jan 2022 22:33:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643265213; cv=none; d=google.com; s=arc-20160816; b=SEuXkJZ3JN1bP0V+2BBCIq81JM2G/TlMVrWzAKnC5aQ9OUL8WC/dBw1urBTcOVdGWw 70SRx2I0iUtFq+tKXGo6UooEUABk+A/XE/bs4PE1+uYCvfDnWpcedJ+uGE9ax9gRRG7w 5MTKcCbUI1L+s5DAQiLRUHlvfPVatlfBtHav3/DiizfAddtDFFL8qPLgOFGpFq5GbJoX u5ddmeCaYfXDrORhVbt6UVn+OuGJxlwDvATgFdldnmDNrC1qNj81wR+G79x95NneiR4X 0mqKKUKpkDKPpDo/OjMOt3bj9czncM8177en21zj/OcFvPLFSXbSp6zI6w86nKWGMgdE AOyQ== 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=QR17iCDr/Cz9CtLK/heYO9ZBbquQ+JtefAe67qGIIlM=; b=z/O2RFgOUByBRMkmsf9a9lnw5jUmEuHVMInVQAuuDwRpYoGblFVYD74uYzM+KNlYmC JImUORwuD1I8uSsK54f9oKR8Ea5IOEg7caMzGWDoP1WpuODgAGyvapwUZip9hEdbr743 06fGalXdu6n/5oAJMYiNnTVoLi16zbGdoJ/U02MpK44sI06YxHW7bVaGGeKlnkyAZf0Z 5llS68VhhosvTo4x8p34NHiPIRUOWEwfZF+FNs5VwEQeiiUjPpQqNjNEwY4QbwUwmav6 2dq+jpXB2ebcMEEpVyQY2lpjV0nhOpHngm6b9AM5XXRxKmrh0hM/BDlGq5WYZ1BYpCz7 O+4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=CvEJl6yR; 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 nc14si944889ejc.529.2022.01.26.22.33.09; Wed, 26 Jan 2022 22:33:33 -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=CvEJl6yR; 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 S230234AbiAZXxe (ORCPT + 99 others); Wed, 26 Jan 2022 18:53:34 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:56552 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbiAZXxd (ORCPT ); Wed, 26 Jan 2022 18:53:33 -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=QR17iCDr/Cz9CtLK/heYO9ZBbquQ+JtefAe67qGIIlM=; b=CvEJl6yR5Dx3unUMT5vBzpqLc6 YHrLLHQDaYO4fo5hefvpWhfaA9SkxZFmb7Potq/YVp8qxkQ+3J9SlVhI03kOg0njZyEAhMJ/s/wZH zVQjB94SAgkxwiJfS51hbnDcYjpOVLeV1OmSYwzyN019I9iiE+GR2ZNXNK8m8rQfJOFU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nCs6T-002sRn-5O; Thu, 27 Jan 2022 00:53:29 +0100 Date: Thu, 27 Jan 2022 00:53:29 +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 2/2] net: dsa: mv88e6xxx: Improve indirect addressing performance Message-ID: References: <20220126231239.1443128-1-tobias@waldekranz.com> <20220126231239.1443128-3-tobias@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220126231239.1443128-3-tobias@waldekranz.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 27, 2022 at 12:12:39AM +0100, Tobias Waldekranz wrote: > Before this change, both the read and write callback would start out > by asserting that the chip's busy flag was cleared. However, both > callbacks also made sure to wait for the clearing of the busy bit > before returning - making the initial check superfluous. The only > time that would ever have an effect was if the busy bit was initially > set for some reason. > > With that in mind, make sure to perform an initial check of the busy > bit, after which both read and write can rely the previous operation > to have waited for the bit to clear. > > This cuts the number of operations on the underlying MDIO bus by 25% > > Signed-off-by: Tobias Waldekranz Reviewed-by: Andrew Lunn Andrew