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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 418F1C34045 for ; Tue, 18 Feb 2020 16:25:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1487324649 for ; Tue, 18 Feb 2020 16:25:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="zIDHrQxr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726652AbgBRQZe (ORCPT ); Tue, 18 Feb 2020 11:25:34 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:55722 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726399AbgBRQZe (ORCPT ); Tue, 18 Feb 2020 11:25:34 -0500 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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To: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=TuGSrvtELJKmIcTw7/lXFrOIqywCrRTKxNNZt6j2szI=; b=zIDHrQxrA7hSQMKjFT/5Wgaky YJVsedvMcMrIA0Oq186C6D6WsSc6xdXZxOwNN39v6eZiw08CVhMZN5/6QACTXqSm7vg7by/N7I6Bi vLhz1Nk5dweWrxImvZQiH6vUAFT7AS5gjk08k8lL/4gcDyu901t/qejvUJJNrHC/ZxY8trbhoTNi5 SYocZZ5ESMMe9zGRVYEjjORsEY8iopdR6/KKfN6EQsFsi3WUbQ3SImgbsCWnlF1EtSxscDVOVC3HO HKCSnVq3VWfHE8kssCu2auajXwVflDXCJe+I7p86tisIojWRpOA4tWotZ8chWqDA649LJSeKPx7iu IznYaGVMQ==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:42040) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1j45gb-0008FW-QW; Tue, 18 Feb 2020 16:25:25 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1j45gY-0000ZK-Ex; Tue, 18 Feb 2020 16:25:22 +0000 Date: Tue, 18 Feb 2020 16:25:22 +0000 From: Russell King - ARM Linux admin To: Dan Murphy Cc: Grygorii Strashko , Florian Fainelli , Heiner Kallweit , andrew@lunn.ch, davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2] net: phy: dp83867: Add speed optimization feature Message-ID: <20200218162522.GH25745@shell.armlinux.org.uk> References: <20200204181319.27381-1-dmurphy@ti.com> <0ebcd40d-b9cc-1a76-bb18-91d8350aa1cd@gmail.com> <170d6518-ea82-08d3-0348-228c72425e64@ti.com> <7569617d-f69f-9190-1223-77d3be637753@gmail.com> <44499cb2-ec72-75a1-195b-fbadd8463e1c@ti.com> <6f800f83-0008-c138-c33a-c00a95862463@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6f800f83-0008-c138-c33a-c00a95862463@ti.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Feb 14, 2020 at 12:31:52PM -0600, Dan Murphy wrote: > Grygorii > > On 2/14/20 12:32 PM, Grygorii Strashko wrote: > > I think it's good idea to have this message as just wrong cable might be > > used. > > > > But this notifier make no sense in it current form - it will produce > > noise in case of forced 100m/10M. > > > > FYI. PHY sequence to update link: > > phy_state_machine() > > |-phy_check_link_status() > >   |-phy_link_down/up() > >     |- .phy_link_change()->phy_link_change() > >     |-adjust_link() ----> netdev callback > > |-phydev->drv->link_change_notify(phydev); > > > > So, log output has to be done or in .read_status() or > > some info has to be saved in .read_status() and then re-used in > > .link_change_notify(). > > > OK I will try to find a way to give some sort of message. How do you know the speed that the PHY downshifted to? If the speed and duplex are available in some PHY specific status register, then one way you can detect downshift is to decode the negotiated speed/duplex from the advertisements (specifically the LPA read from the registers and the advertisement that we should be advertising - some PHYs modify their registers when downshifting) and check whether it matches the negotiated parameters in the PHY specific status register. Alternatively, if the PHY modifies the advertisement register on downshift, comparing the advertisement register with what it should be will tell you if downshift has occurred. Note, however, that if both ends of the link are capable of downshift, and they downshift at the same time, it can be difficult to reliably tell whether the downshift was performed by the local PHY or the remote PHY - even if the local PHY gives you status bits for downshift, you won't know if the remote end downshifted instead. It's a bit like auto MDI/MDIX - if pairswap is needed, either end may do it, and which end does it may change each time the link comes up. So, reporting downshift in the kernel log may not be all that useful, it may be more suited to being reported through a future ethtool interface just like MDI/MDIX. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up