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,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 7B938C433E0 for ; Sat, 13 Feb 2021 00:19:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3ECEC64E9C for ; Sat, 13 Feb 2021 00:19:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229718AbhBMATN (ORCPT ); Fri, 12 Feb 2021 19:19:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229980AbhBMATH (ORCPT ); Fri, 12 Feb 2021 19:19:07 -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 49709C061574 for ; Fri, 12 Feb 2021 16:18:27 -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=SRYockgpuvIyHm/YFs0cpym/SnCSJbFanYtLei8SK9Y=; b=C9m3QOu8vNVhqWh1ZuitFj659 tVUi6Q/lAWCU2l4wnqXtHhYg8exRClZ5bAmIJ3MQbIW4O2uvoq0AVmHV4KvafSQQu2bDiQx0/ZZZq sCa7SOLbdGKVprAf1F5FzHpE42G6D+dlmSQO4L95oxy9VMNen0CoEqe5KUGl8+3gxrgyT1sbJ7vC4 GTPFY/5hOYc6RtdtUuGqzPT7kHyJVNJrrhedJAthoxFxwDWNvPB45thg10uHD57vGJALXvKSicDXz 3MVUP6OnS0UakA9Jb5Vmx/5C6zvZZdjexndRXkqSwrkIfzoFUjYvk0BWy10n8VwPPQd6WFiIldMz8 XJFEzbJDw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:42650) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lAidY-0007no-3k; Sat, 13 Feb 2021 00:18:12 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1lAidU-0007Xw-Ka; Sat, 13 Feb 2021 00:18:08 +0000 Date: Sat, 13 Feb 2021 00:18:08 +0000 From: Russell King - ARM Linux admin To: Michael Walle Cc: Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Antoine Tenart , Quentin Schulz , netdev@vger.kernel.org, Heiner Kallweit , Andrew Lunn , Florian Fainelli , Ioana Ciornei , Maxim Kochetkov , Bjarni Jonasson , Steen Hegelund , UNGLinuxDriver@microchip.com Subject: Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it Message-ID: <20210213001808.GN1463@shell.armlinux.org.uk> References: <20210212172341.3489046-1-olteanv@gmail.com> <20210212172341.3489046-2-olteanv@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote: > Fun fact, now it may be the other way around. If the bootloader doesn't > configure it and the PHY isn't reset by the hardware, it won't work in > the bootloader after a reboot ;) If we start messing around with the configuration of PHYs in that regard, we could be opening ourselves up for a world of pain... > If you disable aneg between MAC and PHY, what would be the actual speed > setting/duplex mode then? I guess it have to match the external speed? That is a function of the interface mode and the PHY capabilities. 1) if the PHY supports rate adaption, and is programmed for that, then the PHY link normally operates at a fixed speed (e.g. 1G for SGMII) and the PHY converts to the appropriate speed. We don't actually support this per se, since the parameters we give to the MAC via mac_link_up() are the media side parameters, not the link parameters. 2) if the PHY does not support rate adaption, then the MAC to PHY link needs to follow the media speed and duplex. phylink will be in "PHY" mode, where it passes the media side negotiation results to the MAC just like phylib would, and the MAC should be programmed appropriately. In the case of a SGMII link, the link needs to be programmed to do the appropriate symbol repetition for 100M and 10M speeds. The PHY /should/ do that automatically, but if it doesn't, then the PHY also needs to be programmed to conform. (since if there's no rate adaption in the PHY, the MAC side and the media side must match.) Hope that helps. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!