* [2.6.37-rc1, patch] gianfar: fix sleep in atomic...
@ 2010-11-02 0:25 Daniel J Blueman
2010-11-08 23:30 ` Rafael J. Wysocki
0 siblings, 1 reply; 4+ messages in thread
From: Daniel J Blueman @ 2010-11-02 0:25 UTC (permalink / raw)
To: David S. Miller; +Cc: Francois Romieu, Linux Kernel
Since device_set_wakeup_enable now sleeps, it should not be called
from a critical section. Since wol_en is not updated elsewhere, we can
omit the locking entirely.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 5c566eb..e641d7c 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -635,10 +635,8 @@ static int gfar_set_wol(struct net_device *dev,
struct ethtool_wolinfo *wol)
if (wol->wolopts & ~WAKE_MAGIC)
return -EINVAL;
- spin_lock_irqsave(&priv->bflock, flags);
priv->wol_en = wol->wolopts & WAKE_MAGIC ? 1 : 0;
device_set_wakeup_enable(&dev->dev, priv->wol_en);
- spin_unlock_irqrestore(&priv->bflock, flags);
return 0;
}
--
Daniel J Blueman
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [2.6.37-rc1, patch] gianfar: fix sleep in atomic...
2010-11-02 0:25 [2.6.37-rc1, patch] gianfar: fix sleep in atomic Daniel J Blueman
@ 2010-11-08 23:30 ` Rafael J. Wysocki
2010-11-09 21:54 ` [PATCH] gianfar: Do not call device_set_wakeup_enable() under a spinlock Rafael J. Wysocki
0 siblings, 1 reply; 4+ messages in thread
From: Rafael J. Wysocki @ 2010-11-08 23:30 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: David S. Miller, Francois Romieu, Linux Kernel, netdev
On Tuesday, November 02, 2010, Daniel J Blueman wrote:
> Since device_set_wakeup_enable now sleeps, it should not be called
> from a critical section. Since wol_en is not updated elsewhere, we can
> omit the locking entirely.
>
> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
> index 5c566eb..e641d7c 100644
> --- a/drivers/net/gianfar_ethtool.c
> +++ b/drivers/net/gianfar_ethtool.c
> @@ -635,10 +635,8 @@ static int gfar_set_wol(struct net_device *dev,
> struct ethtool_wolinfo *wol)
> if (wol->wolopts & ~WAKE_MAGIC)
> return -EINVAL;
>
> - spin_lock_irqsave(&priv->bflock, flags);
> priv->wol_en = wol->wolopts & WAKE_MAGIC ? 1 : 0;
> device_set_wakeup_enable(&dev->dev, priv->wol_en);
> - spin_unlock_irqrestore(&priv->bflock, flags);
>
> return 0;
> }
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] gianfar: Do not call device_set_wakeup_enable() under a spinlock
2010-11-08 23:30 ` Rafael J. Wysocki
@ 2010-11-09 21:54 ` Rafael J. Wysocki
2010-11-12 22:06 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Rafael J. Wysocki @ 2010-11-09 21:54 UTC (permalink / raw)
To: Daniel J Blueman, David S. Miller; +Cc: Francois Romieu, Linux Kernel, netdev
On Tuesday, November 09, 2010, Rafael J. Wysocki wrote:
> On Tuesday, November 02, 2010, Daniel J Blueman wrote:
> > Since device_set_wakeup_enable now sleeps, it should not be called
> > from a critical section. Since wol_en is not updated elsewhere, we can
> > omit the locking entirely.
> >
> > Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
>
> Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Having reconsidered that I think it may be better to do something like in the
patch below.
This is a regression fix, so please apply if there are no objections.
Thanks,
Rafael
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: gianfar: Do not call device_set_wakeup_enable() under a spinlock
The gianfar driver calls device_set_wakeup_enable() under a spinlock,
which causes a problem to happen after the recent core power
management changes, because this function can sleep now. Fix this
by moving the device_set_wakeup_enable() call out of the
spinlock-protected area.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/net/gianfar_ethtool.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/net/gianfar_ethtool.c
===================================================================
--- linux-2.6.orig/drivers/net/gianfar_ethtool.c
+++ linux-2.6/drivers/net/gianfar_ethtool.c
@@ -635,9 +635,10 @@ static int gfar_set_wol(struct net_devic
if (wol->wolopts & ~WAKE_MAGIC)
return -EINVAL;
+ device_set_wakeup_enable(&dev->dev, wol->wolopts & WAKE_MAGIC);
+
spin_lock_irqsave(&priv->bflock, flags);
- priv->wol_en = wol->wolopts & WAKE_MAGIC ? 1 : 0;
- device_set_wakeup_enable(&dev->dev, priv->wol_en);
+ priv->wol_en = !!device_may_wakeup(&dev->dev);
spin_unlock_irqrestore(&priv->bflock, flags);
return 0;
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] gianfar: Do not call device_set_wakeup_enable() under a spinlock
2010-11-09 21:54 ` [PATCH] gianfar: Do not call device_set_wakeup_enable() under a spinlock Rafael J. Wysocki
@ 2010-11-12 22:06 ` David Miller
0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2010-11-12 22:06 UTC (permalink / raw)
To: rjw; +Cc: daniel.blueman, romieu, linux-kernel, netdev
From: "Rafael J. Wysocki" <rjw@sisk.pl>
Date: Tue, 9 Nov 2010 22:54:19 +0100
> The gianfar driver calls device_set_wakeup_enable() under a spinlock,
> which causes a problem to happen after the recent core power
> management changes, because this function can sleep now. Fix this
> by moving the device_set_wakeup_enable() call out of the
> spinlock-protected area.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Patch applied, thank you.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-11-12 22:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-02 0:25 [2.6.37-rc1, patch] gianfar: fix sleep in atomic Daniel J Blueman
2010-11-08 23:30 ` Rafael J. Wysocki
2010-11-09 21:54 ` [PATCH] gianfar: Do not call device_set_wakeup_enable() under a spinlock Rafael J. Wysocki
2010-11-12 22:06 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).