aboutsummaryrefslogtreecommitdiffstats
path: root/arch/m68k/mvme147
diff options
context:
space:
mode:
authorAndreas Bombe <aeb@debian.org>2008-12-10 02:02:19 +0100
committerGeert Uytterhoeven <geert@linux-m68k.org>2009-01-12 20:56:33 +0100
commit6d0be946e150ac17da7381b27fd40603ca40b58f (patch)
tree4795a77c5f43f44441aa7692e25a7ced6e73e0c1 /arch/m68k/mvme147
parentdc8ee69c760317be0bb4eac2bd2fd81eb663627a (diff)
downloadkernel_samsung_tuna-6d0be946e150ac17da7381b27fd40603ca40b58f.zip
kernel_samsung_tuna-6d0be946e150ac17da7381b27fd40603ca40b58f.tar.gz
kernel_samsung_tuna-6d0be946e150ac17da7381b27fd40603ca40b58f.tar.bz2
m68k: amiflop - Get rid of sleep_on calls
Apart from sleep_on() calls that could be easily converted to wait_event() and completion calls amiflop also used a flag in ms_delay() and ms_isr() as a custom mutex for ms_delay() without a need for explicit unlocking. I converted that to a standard mutex. The replacement for the unconditional sleep_on() in fd_motor_on() is a complete_all() together with a INIT_COMPLETION() before the mod_timer() call. It appears to me that fd_motor_on() might be called concurrently and fd_select() does not guarantee mutual exclusivity in the case the same drive gets selected again. Signed-off-by: Andreas Bombe <aeb@debian.org> Acked-by: Jörg Dorchain <joerg@dorchain.net> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Diffstat (limited to 'arch/m68k/mvme147')
0 files changed, 0 insertions, 0 deletions