[net-next,0/9] net: stmmac: further EEE cleanups (and one fix!)

Message

Russell King (Oracle) Jan. 13, 2025, 11:45 a.m. UTC

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(-)

Comments

[e-mail] Jan. 15, 2025, 2:50 a.m. UTC | #1

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <[e-mail]>:

On Mon, 13 Jan 2025 11:45:37 +0000 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [net-next,1/9] net: stmmac: rename stmmac_disable_sw_eee_mode()
    https://git.kernel.org/netdev/net-next/c/900782a029e5
  - [net-next,2/9] net: stmmac: correct priv->eee_sw_timer_en setting
    https://git.kernel.org/netdev/net-next/c/4fe09a0d64d5
  - [net-next,3/9] net: stmmac: simplify TX cleanup decision for ending sw LPI mode
    https://git.kernel.org/netdev/net-next/c/bfa9e131c9b2
  - [net-next,4/9] net: stmmac: check priv->eee_sw_timer_en in suspend path
    https://git.kernel.org/netdev/net-next/c/c920e6402523
  - [net-next,5/9] net: stmmac: add stmmac_try_to_start_sw_lpi()
    https://git.kernel.org/netdev/net-next/c/0cf44bd0c118
  - [net-next,6/9] net: stmmac: provide stmmac_eee_tx_busy()
    https://git.kernel.org/netdev/net-next/c/82f2025dda76
  - [net-next,7/9] net: stmmac: provide function for restarting sw LPI timer
    https://git.kernel.org/netdev/net-next/c/af5dc22bdb5f
  - [net-next,8/9] net: stmmac: combine stmmac_enable_eee_mode()
    https://git.kernel.org/netdev/net-next/c/ec8553673b1f
  - [net-next,9/9] net: stmmac: restart LPI timer after cleaning transmit descriptors
    https://git.kernel.org/netdev/net-next/c/d28e89244978

You are awesome, thank you!