• Anton Vorontsov's avatar
    phylib: Move workqueue initialization to a proper place · 4f9c85a1
    Anton Vorontsov authored
    commit 541cd3ee ("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: default avatarSekhar Nori <nsekhar@ti.com>
    Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
    Tested-by: default avatarSekhar Nori <nsekhar@ti.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    4f9c85a1
phy_device.c 23.8 KB