diff options
| author | Anton Vorontsov <avorontsov@ru.mvista.com> | 2010-01-18 05:37:16 +0000 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2010-01-19 01:59:02 -0800 |
| commit | 4f9c85a1b03bfa5c0a0d8488a3a7766f3c9fb756 (patch) | |
| tree | 33e56a2d442274aeb0baa2f2b61f7bb5759dd17b /tools/perf/util/hist.h | |
| parent | de4ef86cfce60d2250111f34f8a084e769f23b16 (diff) | |
phylib: Move workqueue initialization to a proper place
commit 541cd3ee00a4fe975b22fac6a3bc846bacef37f7 ("phylib: Fix deadlock
on resume") caused TI DaVinci EMAC ethernet driver to oops upon resume:
PM: resume of devices complete after 237.098 msecs
Restarting tasks ... done.
kernel BUG at kernel/workqueue.c:354!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
[...]
Backtrace:
[<c002c598>] (__bug+0x0/0x2c) from [<c0052a54>] (queue_delayed_work_on+0x74/0xf8)
[<c00529e0>] (queue_delayed_work_on+0x0/0xf8) from [<c0052b30>] (queue_delayed_work+0x2c/0x30)
The oops pops up because TI DaVinci EMAC driver detaches PHY on
suspend and attaches it back on resume. Attaching makes phylib call
phy_start_machine() that initializes a workqueue. On the other hand,
PHY's resume routine will call phy_start_machine() again, and that
will cause the oops since we just destroyed the already scheduled
workqueue.
This patch fixes the issue by moving workqueue initialization to
phy_device_create().
p.s. We don't see this oops with ucc_geth and gianfar drivers because
they perform a fine-grained suspend, i.e. they just stop the PHYs
without detaching.
Reported-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/perf/util/hist.h')
0 files changed, 0 insertions, 0 deletions