lkml.org 
[lkml]   [2019]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic
From
Date

On 25/06/2019 08:37, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
>
>> Any further feedback? I am still seeing this issue on today's -next.
>
> Apologies but I was in FTO.
>
> Is there any possibility you can just disable the ethX configuration in
> the rootfs mount and manually configure it after rootfs is done ?
>
> I just want to make sure in which conditions this is happening (if in
> ifdown or ifup).

I have been looking at this a bit closer and I can see the problem. What
happens is that ...

1. stmmac_mac_link_up() is called and priv->eee_active is set to false
2. stmmac_eee_init() is called but because priv->eee_active is false,
timer_setup() for eee_ctrl_timer is never called.
3. stmmac_eee_init() returns true and so then priv->eee_enabled is set
to true.
4. When stmmac_tx_clean() is called because priv->eee_enabled is set to
true, mod_timer() is called for the eee_ctrl_timer, but because
timer_setup() was never called, we hit the BUG defined at
kernel/time/timer.c:952, because no function is defined for the
timer.

The following fixes it for me ...

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -399,10 +399,13 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
mutex_lock(&priv->lock);

/* Check if it needs to be deactivated */
- if (!priv->eee_active && priv->eee_enabled) {
- netdev_dbg(priv->dev, "disable EEE\n");
- del_timer_sync(&priv->eee_ctrl_timer);
- stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
+ if (!priv->eee_active) {
+ if (priv->eee_enabled) {
+ netdev_dbg(priv->dev, "disable EEE\n");
+ del_timer_sync(&priv->eee_ctrl_timer);
+ stmmac_set_eee_timer(priv, priv->hw, 0, tx_lpi_timer);
+ }
+ mutex_unlock(&priv->lock);
return false;
}

It also looks like you have a potention deadlock in the current code
because in the case of if (!priv->eee_active && priv->eee_enabled)
you don't unlock the mutex. The above fixes this as well. I can send a
formal patch if this looks correct.
Cheers
Jon

--
nvpublic

\
 
 \ /
  Last update: 2019-06-25 13:11    [W:0.070 / U:23.868 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site