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=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 8EACDC433E6 for ; Fri, 12 Mar 2021 19:10:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5C81F64F85 for ; Fri, 12 Mar 2021 19:10:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234226AbhCLTKR (ORCPT ); Fri, 12 Mar 2021 14:10:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234144AbhCLTJv (ORCPT ); Fri, 12 Mar 2021 14:09:51 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E07B7C061574 for ; Fri, 12 Mar 2021 11:09:40 -0800 (PST) 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=DCkzR8+e85DChyd/6ktWZc41wjVGKK7x0dAqArN8kys=; b=aCkpLJQzRV39KK4/JCPogvBQ7 u1ew82EcIuQ/odS3zc8tzRW8mkNDRAhwp32RF2eJYX5ASivH0bgsSoDXsKiFsYJabygZPrfzoIT4X 4C5jNWWDiD2NsE8bqI6IuH2V4ufPsBOPvF4Jfik0JMhGGhoUJPLraPT2iBrIzy6I295hq7ce3pWth yZEyUHJ62EM/Wyts/TERA3ykWL5q5PL83EDFqma4XolQtkxOBAMlRxosSJ/+8aGgJS2VsbC32cZG6 6F1Ol3A4X+y7c1D1mkE3+IkcQByvAp/tPCx+Biffjb4i61KPVoRabduP9luPFnmVZ4PYTCh5rP60K hsDafPYaA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:50972) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lKnAE-00070F-0G; Fri, 12 Mar 2021 19:09:34 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1lKnAD-0002nG-3U; Fri, 12 Mar 2021 19:09:33 +0000 Date: Fri, 12 Mar 2021 19:09:33 +0000 From: Russell King - ARM Linux admin To: Joakim Zhang Cc: Florian Fainelli , Jakub Kicinski , Andrew Lunn , Heiner Kallweit , "netdev@vger.kernel.org" Subject: Re: stmmac driver timeout issue Message-ID: <20210312190932.GK1463@shell.armlinux.org.uk> References: <8a996459-fc77-2e98-cc0c-91defffc7f29@gmail.com> <49fedeb2-b25b-10d0-575f-f9808a537124@gmail.com> <5d636daa-b25a-d0f1-dc95-b021cb0f53eb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d636daa-b25a-d0f1-dc95-b021cb0f53eb@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King - ARM Linux admin Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Mar 12, 2021 at 10:33:06AM -0800, Florian Fainelli wrote: > On 3/11/21 4:04 AM, Joakim Zhang wrote: > > I have a question about PHY framework, please point me if something I misunderstanding. > > There are many scenarios from PHY framework would trigger auto-nego, such as switch from power down to normal operation, but it never polling the ack of auto-nego (phy_poll_aneg_done), is there any special reasons? Is it possible and reasonable for MAC controller driver to poll this ack, if yes, at least we have a stable RXC at that time. > > Adding Heiner and Russell as well. Usually you do not want, or rather > cannot know whether auto-negotiation will ever succeed, so waiting for > it could essentially hog your system for some fairly indefinite amount > of time. I think the question being asked is essentially whether checking the link status bit (1.2) without checking the aneg complete bit (1.5) is sufficient. Reading 802.3, it seems to be defined that if autonegotiation is in use, the link shall be reported as down until autonegotiation has completed - which is logical. The link can only be up if a valid data path capable of transferring data has been established, which implies that autonegotiation must have completed. However, note that when coming out of power down, there is no guarantee that there is anything connected to the other side of the media, and thus there is no guarantee that autonegotiation will complete. Waiting for autonegotiation to complete in this case would not be feasible. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!