aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/ramips/base-files/etc/board.d/02_network
diff options
context:
space:
mode:
authorAndrea Merello <andrea.merello@gmail.com>2017-07-08 10:11:11 +0200
committerMathias Kresin <dev@kresin.me>2017-07-20 19:10:29 +0200
commitb81c04382b5ddea0164993c2af0df7270bb95ee4 (patch)
tree0d277e90337a8c8ef304da6e6c93ef0c376510aa /target/linux/ramips/base-files/etc/board.d/02_network
parent34c01e68b5d6b06ce3794ef0e2b06e81ec3ce8ca (diff)
downloadupstream-b81c04382b5ddea0164993c2af0df7270bb95ee4.tar.gz
upstream-b81c04382b5ddea0164993c2af0df7270bb95ee4.tar.bz2
upstream-b81c04382b5ddea0164993c2af0df7270bb95ee4.zip
lantiq: fix sleep with spinlock held in xrx200 network driver
In the xrx200_close() function we call napi_disable(), that could sleep, with priv->hw->chan[i].lock held. This could lead to deadlock and causes the kernel to complain. Look at the code I couldn't convince myself about why we need to protect that specific code part with the lock. IMHO there seems no reason to protect the refcount variables, because AFAIK ndo_close() and ndo_open() callbacks are already called with a semaphore held. Neither I could figure out why napi_disable() have to be called with that lock held. The only remaining code part for which I could guess the lock is useful for is ltq_dma_close() function call. This patch reduces the lock to the said function call, avoiding the sleep-with-spinlock-held situation Signed-off-by: Andrea Merello <andrea.merello@gmail.com> [fold into 0025-NET-MIPS-lantiq-adds-xrx200-net.patch, backport to kernel 4.4] Signed-off-by: Mathias Kresin <dev@kresin.me>
Diffstat (limited to 'target/linux/ramips/base-files/etc/board.d/02_network')
0 files changed, 0 insertions, 0 deletions