From patchwork Mon Dec 9 14:22:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Russell King (Oracle)" X-Patchwork-Id: 13899870 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (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 B546F1B0421 for ; Mon, 9 Dec 2024 14:22:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733754167; cv=none; b=hElVrN3zFXO5Rr5JUDtJF8sf+GuX4mWbPpIQMXAPOrRixXX5ANnS1tuV+Vs3gRJB6yTmhUS2Kf/cmqhEskxgI1PH5qWHi/n5cGWALoocjw/1241YFI6LIyWB8hEEFr/vnJKQxsW9WUA+xY6CxyjA6dNWkq9fF/DnfeXvuWXW1p0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733754167; c=relaxed/simple; bh=Nksm2B7YF/kxpTNDqcK9kU3i2yzLbmwGJNb6iIx/Kpk=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=bx6VX2qNqdxZI55VqUEOCXkRta0/6lWAmMT2nk7bWdn/9h+QpsrHzDoKu3oLMSPXcEMTSI1lY3jde7FiUrxSPDCoYX1FHZEDNhYKd7mXQSFdj3csKvAESo2vTyvFFD1wx9zzF5EEPTISP7UVy9ow7nYGnmydXqczXQn+Ct4X7yY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=g4NOJPQo; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="g4NOJPQo" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:Content-Type:MIME-Version: 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:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=K6jgVBpRZHxQ5DEqLZmFTAzvfUkownFqChtoVmYYGe0=; b=g4NOJPQou20GUDtPikUps6+r+R 2LKLITAARSNn7nMVvamh6g/2cDhb8mPDJ8dM0+lVJltp6um92jEWqO3A+ZgOAT73BoO31lEipmI1y VGy+JSX/IN/cRtMLyqzoONggk3YhEmXdVRZXwyIC33Nn2gT7sFrl/hqx2zAgId2ryBhiLJmqbYrBh +oNVnICubueFwDcECqYq8+IAkGJbh7mqBbpuC8O2kYWkyeYytggbP5IHfFrBIOs0wh1e81VtaFwkD uhFX0AZnhCYdiYc/RSX46aB08tIjjLE1bvjvTBiclXCaYvdpp1EacEwRjR4agaZ3AY7MPNwdTckfc y4zK0QBA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:57612) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tKeeg-0000w1-1v; Mon, 09 Dec 2024 14:22:35 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1tKeed-00022f-2h; Mon, 09 Dec 2024 14:22:31 +0000 Date: Mon, 9 Dec 2024 14:22:31 +0000 From: "Russell King (Oracle)" To: Andrew Lunn , Heiner Kallweit Cc: Andrew Lunn , Bryan Whitehead , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Marcin Wojtas , netdev@vger.kernel.org, Paolo Abeni , UNGLinuxDriver@microchip.com Subject: [PATCH net-next 00/10] net: add phylink managed EEE support Message-ID: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Sender: Russell King (Oracle) X-Patchwork-Delegate: kuba@kernel.org Hi, Adding managed EEE support to phylink has been on the cards ever since the idea in phylib was mooted. This overly large series attempts to do so. I've included all the patches as it's important to get the driver patches out there. Patch 1 adds a definition for the clock stop capable bit in the PCS MMD status register. Patch 2 adds a phylib API to query whether the PHY allows the transmit xMII clock to be stopped while in LPI mode. This capability is for MAC drivers to save power when LPI is active, to allow them to stop their transmit clock. Patch 3 adds another phylib API to configure whether the receive xMII clock may be disabled by the PHY. We do have an existing API, phy_init_eee(), but... it only allows the control bit to be set which is weird - what if a boot firmware or previous kernel has set this bit and we want it clear? Patch 4 starts on the phylink parts of this, extracting from phylink_resolve() the detection of link-up. (Yes, okay, I could've dropped this patch, but with 23 patches, it's not going to make that much difference.) Patch 5 adds phylink managed EEE support. Two new MAC APIs are added, to enable and disable LPI. The enable method is passed the LPI timer setting which it is expected to program into the hardware, and also a flag ehther the transmit clock should be stopped. *** There are open questions here. Eagle eyed reviewers will notice pl->config->lpi_interfaces. There are MACs out there which only support LPI signalling on a subset of their interface types. Phylib doesn't understand this. I'm handling this at the moment by simply not activating LPI at the MAC, but that leads to ethtool --show-eee suggesting that EEE is active when it isn't. *** Should we pass the phy_interface_t to these functions? *** Should mac_enable_tx_lpi() be allowed to fail if the MAC doesn't support the interface mode? The above questions remain unanswered from the RFC posting of this series. A change that has been included over the RFC version is the addition of the mac_validate_tx_lpi() method, which allows MAC drivers to validate the parameters to the ethtool set_eee() method. Implementations of this are in mvneta and mvpp2. An example of a MAC that this is the case are the Marvell ones - both NETA and PP2 only support LPI signalling when connected via SGMII, which makes being connected to a PHY which changes its link mode problematical. The remainder of the patches address the driver sides, which are necessary to actually test phylink managed EEE. drivers/net/ethernet/marvell/mvneta.c | 127 +++++++++++-------- drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 5 + drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 98 +++++++++++++++ drivers/net/ethernet/microchip/lan743x_ethtool.c | 21 ---- drivers/net/ethernet/microchip/lan743x_main.c | 39 ++++-- drivers/net/ethernet/microchip/lan743x_main.h | 1 - drivers/net/phy/phy.c | 47 ++++++- drivers/net/phy/phylink.c | 150 +++++++++++++++++++++-- include/linux/phy.h | 2 + include/linux/phylink.h | 59 +++++++++ include/uapi/linux/mdio.h | 1 + 11 files changed, 458 insertions(+), 92 deletions(-)