Gui-Dong Han 7ddb521ab0 gpib: Move stuck SRQ update under lock ... Move the stuck SRQ state update into autopoll_all_devices() and keep it under big_gpib_mutex. Except for initialization, keep the stuck_srq users under this mutex. autopoll_all_devices() is only called by autospoll_thread(), so there is no need to return to autospoll_thread() and set this state after dropping big_gpib_mutex. Without the mutex, a newly opened device can clear stuck_srq and have that clear overwritten by the previous autospoll result: autospoll: serial_poll_all() returns 0 and unlocks big_gpib_mutex open_dev_ioctl: open new device and clear stuck_srq with big_gpib_mutex held autospoll: set stuck_srq That leaves the board marked stuck again after the new device is opened. autospoll_wait_should_wake_up() then refuses to poll while stuck_srq is set, so later SRQ handling can be mistakenly suppressed. Without the mutex, atomic_set() and set_bit() only make individual updates atomic. They do not order the two updates or make stuck_srq and status visible as a consistent pair. Taking big_gpib_mutex serializes the state transition with the other runtime users. Keep the existing wakeup behavior unchanged and only move the stuck SRQ state update under the mutex. Fixes: 9dde4559e9 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://patch.msgid.link/20260522073447.4117690-1-hanguidong02@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>		2026-07-17 14:53:47 +02:00
..
gpib_os.c	gpib: Move stuck SRQ update under lock	2026-07-17 14:53:47 +02:00
iblib.c	gpib: Move stuck SRQ update under lock	2026-07-17 14:53:47 +02:00
ibsys.h
Makefile