From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DDC3C43460 for ; Fri, 23 Apr 2021 12:38:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8A5E613DE for ; Fri, 23 Apr 2021 12:38:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236514AbhDWMjL (ORCPT ); Fri, 23 Apr 2021 08:39:11 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:37888 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbhDWMjJ (ORCPT ); Fri, 23 Apr 2021 08:39:09 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1lZv4j-000eNb-E5; Fri, 23 Apr 2021 14:38:25 +0200 Date: Fri, 23 Apr 2021 14:38:25 +0200 From: Andrew Lunn To: Ansuel Smith Cc: Florian Fainelli , Vivien Didelot , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Rob Herring , Heiner Kallweit , Russell King , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/14] drivers: net: mdio: mdio-ip8064: improve busy wait delay Message-ID: References: <20210423014741.11858-1-ansuelsmth@gmail.com> <20210423014741.11858-4-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210423014741.11858-4-ansuelsmth@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 23, 2021 at 03:47:29AM +0200, Ansuel Smith wrote: > With the use of the qca8k dsa driver, some problem arised related to > port status detection. With a load on a specific port (for example a > simple speed test), the driver starts to bheave in a strange way and > garbage data is produced. To address this, enlarge the sleep delay and > address a bug for the reg offset 31 that require additional delay for > this specific reg. > struct ipq8064_mdio { > struct regmap *base; /* NSS_GMAC0_BASE */ > @@ -65,7 +66,7 @@ ipq8064_mdio_read(struct mii_bus *bus, int phy_addr, int reg_offset) > ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK); > > regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr); > - usleep_range(8, 10); > + usleep_range(10, 13); > > err = ipq8064_mdio_wait_busy(priv); > if (err) > @@ -91,7 +92,14 @@ ipq8064_mdio_write(struct mii_bus *bus, int phy_addr, int reg_offset, u16 data) > ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK); > > regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr); > - usleep_range(8, 10); > + > + /* For the specific reg 31 extra time is needed or the next > + * read will produce grabage data. > + */ > + if (reg_offset == 31) > + usleep_range(30, 43); > + else > + usleep_range(10, 13); > > return ipq8064_mdio_wait_busy(priv); Is there any documentation as to what register 31 does? Maybe the real problem is in ipq8064_mdio_wait_busy()? Have you looked at how long you typically end up waiting? If you know the MDIO bus speed, you can work out how long a transaction should take. If it is taking less, something is broken. Are you sure regmap caching is disabled, so that ipq8064_mdio_wait_busy() really is reading the register, not some old cached value? Andrew > } > -- > 2.30.2 >