From patchwork Mon Jan 13 11:45:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Russell King (Oracle)" X-Patchwork-Id: 13937210 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 DB71722CF30 for ; Mon, 13 Jan 2025 11:45:52 +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=1736768754; cv=none; b=g5DvQ1/vjRvRSjVD8/Eluq/3MeNUIpeltXodIhxtWbUv6V+kQgwGyg9OwlnmomEh62IK/E8berVYUrm08sLVUs16VUf/EOais3o27pdGUn/r2rRjOshLgEsYEkCFuVCmmiWqlnUOpmpdI2rfJPY5q0Q7BDxMcJYSJunlLj+1h0g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736768754; c=relaxed/simple; bh=lM19slQSzr84yEo2MfTfOOnbwx+ie3cshz0kSwx98HY=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=LWEWfDHhGCQ1i6DYgfiFJSLlsuHVb8riogWsXOg76rTZlej6dT5gvkJdKoA6Ya11zCC+s8ALIoO+gDEucQuEKXCYX7lyy7ruzTf6rvxnaCrZe66ZgnszbVyeoFgizSzXKpkAORc/9jVuVmX+1Q5t5r9GtEzWvGb0cLA4WPYjnuQ= 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=HbV//J92; 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="HbV//J92" 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=rbT7xplslF0DCwfG1zTGk6wwOgd2peDWsm8gQHEx3QU=; b=HbV//J923OKFzYQsHCa/mYJO0C 9uuIYF46MTKqOgpdamOhMHRV+Wm9SIPPz91V3memmxMaE/Qvruj7Qa1HlS6zQUHdjMwaedD5hXUP5 25q7Z3fpmeUVaxOsEIQWB0HFGwIbMmC5js2OhLEieEh1+ld6qW61bVOE/pKMp45QWEctF4pLwR62+ mYMXdMNCIfc5usr9g7m7sv3Vumj9ERgypVSYZTPCuxmR2nZtsLg4pnovVXSG8XsQ1Iq1bQYzIt2DJ bqK7ZxiyrLDLtM01HHbmbFtTQX6pRn6rg7c8BgN4S+psaC1cJDcFdP+6fagisCsJ36P7t3VI78DrS F6U8pnyQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:58056) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tXIt3-0006Ue-02; Mon, 13 Jan 2025 11:45:41 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1tXIsz-00042f-1U; Mon, 13 Jan 2025 11:45:37 +0000 Date: Mon, 13 Jan 2025 11:45:37 +0000 From: "Russell King (Oracle)" To: Andrew Lunn , Heiner Kallweit Cc: lexandre Torgue , Andrew Lunn , "David S. Miller" , Eric Dumazet , Eric Woudstra , Jakub Kicinski , linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, Maxime Coquelin , netdev@vger.kernel.org, Paolo Abeni Subject: [PATCH net-next 0/9] net: stmmac: further EEE cleanups (and one fix!) 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, This series continues the EEE cleanup of the stmmac driver, and includes one fix. As mentioned in the previous series, I wasn't entirely happy with the "stmmac_disable_sw_eee_mode" name, so the first patch renames this to "stmmac_stop_sw_lpi" instead, which I think better describes what this function is doing - stopping the transmit of the LPI state because we have a packet ot send. Patch 2 corrects the priv->eee_sw_timer_en flag when EEE has been disabled. Currently upon disable, priv->eee_enabled is set false, but through the weird logic that was present prior to the previous series, priv->eee_sw_timer_en was set true. This behaviour was kept as the previous series was cleanup, not fixes. This patch fixes this. Having fixed priv->eee_sw_timer_en to actually indicate whether software timed EEE mode is being used, it becomes no longer necessary to test priv->eee_enabled in addition. Patch 3 removes the redundant test. Patch 4 also uses priv->eee_sw_timer_en before manipulating the software EEE state in the suspend method rather than using priv->eee_enabled, which brings consistency. Patch 5 provides stmmac_try_to_start_sw_lpi() which complements stmmac_stop_sw_lpi(), and allows us to move duplicated code into one location. Patch 6 splits stmmac_enable_eee_mode() - one part of this function tests whether there are any queues that have unfinished work (in other words are busy). Separate out this code into a separate function. Patch 7 also splits out the mod_timer() for the software EEE timer intoi a seperate function (the reason will be in patch 9.) Patch 8 merges the remains of stmmac_enable_eee_mode() into stmmac_try_to_start_sw_lpi(). Patch 9 fixes the delay between transmit and entering LPI. Currently, when cleaning the transmit queues, if we discover that we have finished cleaning up all queues, we immediately instruct the hardware to enter LPI mode without waiting for the LPI timer. However, we should wait for the LPI timer to expire. Therefore, the transmit cleanup path needs to call stmmac_restart_sw_lpi_timer() instead of stmmac_try_to_start_sw_lpi(). drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 58 +++++++++++++---------- 1 file changed, 33 insertions(+), 25 deletions(-)