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.1 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 154F1C4332D for ; Thu, 19 Mar 2020 13:58:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B62C720663 for ; Thu, 19 Mar 2020 13:58:12 +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="DPVBOy2z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727408AbgCSN6M (ORCPT ); Thu, 19 Mar 2020 09:58:12 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:44936 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727180AbgCSN6L (ORCPT ); Thu, 19 Mar 2020 09:58:11 -0400 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=JbcPGnuINlXiKU7pzfjGVNxHgU8/NfDj/roK0Ui4qiU=; b=DPVBOy2zVfGVA8Cpqv7+H391u St7kcwC+IcZ+vYgDu8D3FaYNqbsUD8XJFP8wjhoU2Pit1qI8hVuEXSpUofUXT4dIAfZdV9kHpaQmY 431WkSrxlxo5iw0i5SmB7h/ITiWatGlkPD6Tckxkr9zJCfZqLW099IPR525SmFwP9bqRlUtvaEVCK P4r7C39YccyofAsAynL3n8cb8yozNs2Rj+ZslbZLhalVYY3rrQs9NoAb8swiMRuPhVv9JP+oLqRiI JSVVf+3VT8CK2RaRno7jiGQBOmVuLASirvix/a7fuFQjZwZZeMgX2+7eZ97LQBm1doG+BJ1YJLlfY CojyAPiag==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:55152) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jEvgR-0002WF-Ak; Thu, 19 Mar 2020 13:58:03 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jEvgO-0004pZ-NJ; Thu, 19 Mar 2020 13:58:00 +0000 Date: Thu, 19 Mar 2020 13:58:00 +0000 From: Russell King - ARM Linux admin To: Andrew Lunn Cc: Heiner Kallweit , Florian Fainelli , David Miller , "netdev@vger.kernel.org" Subject: Re: [PATCH net-next 1/3] net: phy: add and use phy_check_downshift Message-ID: <20200319135800.GE25745@shell.armlinux.org.uk> References: <6e4ea372-3d05-3446-2928-2c1e76a66faf@gmail.com> <20200318232159.GA25745@shell.armlinux.org.uk> <20200319112535.GD25745@shell.armlinux.org.uk> <20200319130429.GC24972@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200319130429.GC24972@lunn.ch> 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 Thu, Mar 19, 2020 at 02:04:29PM +0100, Andrew Lunn wrote: > > The only time that this helps is if PHY drivers implement reading a > > vendor register to report the actual link speed, and the PHY specific > > driver is used. > > So maybe we either need to implement this reading of the vendor > register as a driver op, or we have a flag indicating the driver is > returning the real speed, not the negotiated speed? I'm not sure it's necessary to have another driver op. How about this for an idea: - add a flag to struct phy_device which indicates the status of downshift. - on link-up, check the flag and report whether a downshift occurred, printing whether a downshift occurred in phy_print_status() and similar places. (Yes, I know that there are some network drivers that don't use phy_print_status().) The downshift flag could be made tristate - "unknown", "not downshifted" and "downshifted" - which would enable phy_print_status() to indicate whether there is downshift supported (and hence whether we need to pay more attention to what is going on when there is a slow-link report.) Something like: For no downshift: Link is Up - 1Gbps/Full - flow control off For downshift: Link is Up - 100Mbps/Full (downshifted) - flow control off For unknown: Link is Up - 1Gbps/Full (unknown downshift) - flow control off which has the effect of being immediately obvious if the driver lacks support. We may wish to consider PHYs which support no downshift ability as well, which should probably set the status to "not downshifted" or maybe an "unsupported" state. This way, if we fall back to the generic PHY driver, we'd get the "unknown" state. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up