From mboxrd@z Thu Jan 1 00:00:00 1970 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 DE6C12D8393 for ; Wed, 1 Apr 2026 15:05:49 +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=1775055951; cv=none; b=D3e/6usJfgG5q7zq/r4jhHsKYTkV4tO8gTNDHSBt9W8CfaRv6lcwGBfFNgYMl3DLq1eej+TnwiPu14voZtRokxcABKY7JfR6eCV+DQ/vcCwcG3WaE8NyRMURGpbh7TFPvqat1sEzeieOocF1YohuPUc2MiZq3pkf6PFR24XqnMc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775055951; c=relaxed/simple; bh=K47QYkFPRa4LBLpvz2j90GLJBZw76Ip8q8b98zq762Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FY2+3d2hYm+6eJwMFEDS633N/09dzUt1OJ2f1Fo7TsBN0ugPry7acNutIGR1M/+TsGmFeyn7yp6wyQjgrZxixtyjqy4ZF0cphocjapMzsDvBBfvO4o7SjaLW2HuPPNp6YFySFvkXtVVZP4pRdOc5SUcCJPxN5I+8pHllvkysJDM= 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=yCQz9F5O; 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="yCQz9F5O" 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=+Fd0lPt2RDH2WakZNw3VBaW4YCoeOwMD8IQTHdhWaQc=; b=yCQz9F5O/2oH7Lthszd0K8qPWG HaM/xlOlrCCCeDOxV6surFqMrhjB83QhzAeM0CL2PmCdD5zgIO541cMrqKxqx4SBtYQRPxqF6U2J+ qMGNH359fotdm9c+JWIFkKfDaEYsKO88UqdI34+oi65buaJt3/m8YOLven/N/4dOddoa0UceS9NFt H078uccdZv58w1Q1e6YmYJw5KM2r5UKNl0YsI7ZIzGc+9LMpEodqH9VNufbSzdMvoY+rAKN+NOoXj qwDSHKLVMaFDPkJ/PtTAsgLLSLd6yQB2Oeh6qOivxRv/neCsHcbB+dn9qVXtkGhInMqDcios7W44F WZi1w8mg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:53234) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w7x8d-000000003Kz-2QJR; Wed, 01 Apr 2026 16:05:47 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1w7x8O-000000004sC-29sh; Wed, 01 Apr 2026 16:05:32 +0100 Date: Wed, 1 Apr 2026 16:05:32 +0100 From: "Russell King (Oracle)" To: Andrew Lunn Cc: Nicolai Buchwitz , netdev@vger.kernel.org Subject: Re: RFC: phylink: disable PHY autonomous EEE when MAC manages LPI Message-ID: References: <04ff15af-26be-4278-bc2a-889e7802d271@lunn.ch> <48abd3e3-a3ee-4e85-a3d8-20c8ceedfb77@lunn.ch> 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: <48abd3e3-a3ee-4e85-a3d8-20c8ceedfb77@lunn.ch> Sender: Russell King (Oracle) On Wed, Apr 01, 2026 at 03:11:24PM +0200, Andrew Lunn wrote: > > Thanks Russell and Andrew. You're both heading in the same direction, > > so to make sure I understand correctly: > > > > 1. Add a new phylib interface (separate from phy_ethtool_set_eee) to > > control PHY-autonomous EEE, e.g. phy_set_autonomous_eee(phydev, > > enable) and phy_get_autonomous_eee(phydev) to query the current > > state. > > In the end, we want the MAC driver using phylib to just call the > phylib methods for configuring EEE, and the MAC driver should not care > if EEE is actually implemented in the PHY or the MAC. The adjust_link > callback would simply not enable LPI if the PHY is doing EEE. This won't work. If we mask out eee.tx_lpi_enabled when calling into phylib to tell phylib drivers to disable SmartEEE (that's what I'm calling it here because it's easier to type)), then phylib records that tx_lpi_enabled was false. This then makes the following in phy_check_link_status(): phydev->enable_tx_lpi = phydev->eee_cfg.tx_lpi_enabled && phydev->eee_active; set phydev->enable_tx_lpi to false, which in turn tells the MAC driver or phylink not to enable LPI. So, we lose the ability to use EEE - a regression - because we're overloading tx_lpi_enabled to mean "disable SmartEEE" at the PHY. To work around this, we'd need to go back to the old days of EEE and have each and every MAC driver resolve the EEE state themselves because phylib's resolution will now always teoo the MAC driver to disable LPI. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!