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 4E1923D6CA4 for ; Wed, 1 Apr 2026 16:02:26 +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=1775059347; cv=none; b=Tv/F4BItt+D3Mcevd8OxrVLHx4vHVo9geSPpoZ2waqRDPzsFfOdpy7MN+uVf4a6e613iAGWZmupQwRUegE2l2Cx9S+Xr6zNBaJA1lSqg+8464b/cfztVkIi+6ryNF7fZM9BxRpgnLlMfuvEic3RPHKlyhwCZ0LpgQXq975HFRXo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775059347; c=relaxed/simple; bh=nQsy9CmugKTeEDDnlV7xv6TBP6e8voyaERAwTP3s76s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MIeWJ7Lq08o2cxU/kAjjjmqLYSRPLtBF4exMadXmzX0Ia5mTHS3i764F6xPVZUyQrOz56KUpwp1vcgBVnj73qJMGKTbe5NrlddAuLRokLmf7eBoavPiRlIowxbky/jbNo7qjvo6z3/Y8ngCuF/qNd6qXIzseFB53iO113aFYO9A= 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=fRbmQFeQ; 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="fRbmQFeQ" 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=p40naoSfNGuwBVmANaXrE1JyuzEqjPS+rTBwoiTOT80=; b=fRbmQFeQBdRsFwmK3kVI7W4UIK 5ATU8MZ7xi7uYPQgBF7ZDM+mp+VRb1g4DNfD9oRkUlNL3JBsMKiViF9BH21jLOLhbgwTy4Z3Y0Rrc gVIl7bZB169dWpSV5Qh826wtgA7/3HQbt8a2cDJx2bZ1xlRC9N6WIDc0EGoBgJg72hhQuNEVrckuk JEmN2mh+sD1oZ7NjF9Xf7PSHctyR3kvPbDnr+i6L5L+bzl69ToFGayvP8smqd0xjYD98pgF99a50R omOs5BpHlaU38FOGr6LHLJkt8+TNI/FZ8TzAnZlE2kFmNtu64+/fntr/o2iDBMWFmMed8qqJyAZTZ iDpZqVDQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:53882) 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 1w7y1Q-000000003OQ-1CBq; Wed, 01 Apr 2026 17:02:24 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1w7y1P-000000004uY-0rAr; Wed, 01 Apr 2026 17:02:23 +0100 Date: Wed, 1 Apr 2026 17:02:23 +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: Sender: Russell King (Oracle) On Wed, Apr 01, 2026 at 05:38:23PM +0200, Andrew Lunn wrote: > On Wed, Apr 01, 2026 at 04:05:32PM +0100, Russell King (Oracle) wrote: > > 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)), > > We need phylib to handle some state information. Are we doing MAC EEE > or SmartEEE? We can then set phydev->enable_tx_lpi == True to indicate > if the MAC should be sending LPI indications, if and only if the > phylib knows we are doing MAC EEE and it should be enabled because the > user said so. Right, and that's why I suggested phy_disable_autonomous_eee() to tell phylib to disable SmartEEE/autonomous EEE support at the PHY independent of phy_ethtool_set_eee(). I was also suggesting that there's eventually a complementary function that says basically "please enable SmartEEE" because we may have phy drivers that disable it today. In absence of either call, phy drivers need to maintain their current state. > However, i think this is down the road. If the MAC driver calls > phy_support_eee(), we should call the SmartEEE disable method of the > PHY driver. When we add support for SmartEEE then we need this > additional state information. That also works for me. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!