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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F1C2C7EE23 for ; Thu, 1 Jun 2023 12:02:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233293AbjFAMCt (ORCPT ); Thu, 1 Jun 2023 08:02:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233254AbjFAMCm (ORCPT ); Thu, 1 Jun 2023 08:02:42 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA24EE71; Thu, 1 Jun 2023 05:02:13 -0700 (PDT) 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=KV3wHUujsSOxU/oeIXKi+3r4Hg4NKOWlza+5RYzc5H4=; b=RnpPZu0KctrNBkYvsUddgdvG37 dzbZhCKkPvYGI3KbQgO0PbpGVaP/2i6L7q0IOb87fkppGlNM6EQmQhbKZhVl+UjWzqjXsy16cvjFS WD9CLqPNm0nmOZggyZEGW+hj0/e6KOZN7AZYi2UBREAhKQv1L1y84aBVuVuYChIzRdd8=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1q4h04-00EZ39-6U; Thu, 01 Jun 2023 14:01:52 +0200 Date: Thu, 1 Jun 2023 14:01:52 +0200 From: Andrew Lunn To: Andreas Svensson Cc: Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , kernel@axis.com, Baruch Siach , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset deactivation Message-ID: <133860f9-e745-44ce-9b74-c5d990cf92db@lunn.ch> References: <20230530145223.1223993-1-andreas.svensson@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 01, 2023 at 11:10:58AM +0200, Andreas Svensson wrote: > On 5/30/23 19:28, Andrew Lunn wrote: > > On Tue, May 30, 2023 at 04:52:23PM +0200, Andreas Svensson wrote: > > > A switch held in reset by default needs to wait longer until we can > > > reliably detect it. > > > > > > An issue was observed when testing on the Marvell 88E6393X (Link Street). > > > The driver failed to detect the switch on some upstarts. Increasing the > > > wait time after reset deactivation solves this issue. > > > > > > The updated wait time is now also the same as the wait time in the > > > mv88e6xxx_hardware_reset function. > > > > Do you have an EEPROM attached and content in it? > > There's no EEPROM attached to the switch in our design. > > > > > It is not necessarily the reset itself which is the problem, but how > > long it takes after the reset to read the contents of the > > EEPROM. While it is doing that, is does not respond on the MDIO > > bus. Which is why mv88e6xxx_hardware_reset() polls for that to > > complete. > > Ok, yes that makes sense. I could add the mv88e6xxx_g1_wait_eeprom_done > function after the reset deactivation. I don't think that works, because how to talk to the switch is not determined until after the switch has been detected. > The datasheet for 88E6393X also states that it needs at least 10ms > before it's ready. But I suppose this varies from switch to switch. O.K, let go with this change and see if anybody really complains. We can always add a DT property later. Reviewed-by: Andrew Lunn You probably need to repost with my Reviewed-by added, now that Paolo has changed the status of the patch. Andrew