Arnd,
this one looks like it should be changed as well:
@@ -562,7 +565,10 @@ static void falcon_get_lock(void)
falcon_trying_lock = 0;
wake_up(&falcon_try_wait);
} else {
- sleep_on(&falcon_try_wait);
+ wait_event_cmd(falcon_try_wait,
+ !falcon_got_lock &&
!falcon_trying_lock,
I think using falcon_got_lock && !falcon_trying_lock here reflects what
we try to achieve - the if branch above this will set that exact
condition, then wake the wait queue. Any other calls to falcon_get_lock
that have been waiting on the lock should then continue on
as the lock is now held by the driver. Thoughts?
I've not see that case used in a cursory test on hardware, more stress
testing is needed (logging lock history to a kernel buffer instead
of clogging up the console).
Cheers,
Michael
+ local_irq_restore(flags),
+ local_irq_save(flags));
}
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe
linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
