From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2E03101FB for ; Sun, 11 Jun 2023 21:38:06 +0000 (UTC) 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 E7569E41 for ; Sun, 11 Jun 2023 14:38:03 -0700 (PDT) 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=looin07insiW0ALScIgfJP68Sm0rrKxa54BqB7o7p/I=; b=qDTlIPk+/mJB46rjLbJ5eighK0 mGt483iADEyJ/M/kWYgHbQmDTOAT+XMqEEJBUSVa56IXOO8DJ9r/TBCyJKu0wF07ywxIaBNVmJXLv AMeQUk/EZ7rOtUY+5/v9YqFxckRVawhnkkVYjg1qOvLBoLoV+iv/rb0b6EAj9qHB0Tl3YKJmusePj YrkYm3Cb/oTOKOGzJ3MB5LZy6bUsVXe6XlG+4RVU65dIeckPTh/gVeVeu+TPex6yx1Gxrhs1ptim1 YJncgmyuF28dK8OtfuZPbCySBF5GgWWuHnF+GjG+37ya6nt3YPA5AVD+2XVqFJvC9QEkPcO/DxVXv r9pGmJmg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33288) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q8Sl4-0004mC-1S; Sun, 11 Jun 2023 22:37:58 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q8Sl1-0004HI-DY; Sun, 11 Jun 2023 22:37:55 +0100 Date: Sun, 11 Jun 2023 22:37:55 +0100 From: "Russell King (Oracle)" To: Andrew Lunn Cc: Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Marcin Wojtas , netdev@vger.kernel.org, Paolo Abeni , Thomas Petazzoni Subject: Re: [PATCH RFC net-next 2/4] net: phylink: add EEE management Message-ID: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Sun, Jun 11, 2023 at 11:28:32PM +0200, Andrew Lunn wrote: > On Fri, Jun 09, 2023 at 10:11:21AM +0100, Russell King (Oracle) wrote: > > Add EEE management to phylink. > > Hi Russell > > I've been working on my EEE patches. I have all pure phylib drivers > converted. I've incorporated these four patches as well, and make use > of the first patch in phylib. > > Looking at this patch, i don't see a way for the MAC to indicate it > actually does support EEE. Am i missing it? If a MAC doesn't support EEE, it won't have the necessary calls to phylink_*_eee() in its ethtool ops. As can be seen from the mvpp2 patch, mvpp2_ethtool_get_eee() and mvpp2_ethtool_set_eee() are needed to call the phylink methods. Given that a MAC has to provide those hooks, why would we need a capability for EEE? Are you thinking that it may be optional for some MACs? Thinking of the future (not having done a lot of research though) it may be appropriate to have a bitmap of... I was going to say ethtool modes but that doesn't really work... phy interface modes that the MAC can support EEE. I'm thinking of devices such as mvpp2 where EEE is supported by the GMAC (for <=2.5G) but not XLG (for >= 5G). If we use phy interface modes, we somehow need to turn that into ethtool link modes for the media side, which is e.g. PHY dependent. For example, the Aquantia PHYs doing rate adaption to 10G plugged into mvpp2 (which probably doesn't work too well due to the lack of pause support in mvpp2 hardware) won't be able to do EEE at any speed because it'll be only using the XLG, but a PHY that uses SGMII connected to mvpp2 can because that will use GMAC. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!