Bluetooth: use wait_event API instead of open-coding it
I've seen timeout errors from HCI commands where it looks like schedule_timeout() has returned immediately; additional logging for the error case gives: req_status=1 req_result=0 remaining=10000 jiffies so the device is still in state HCI_REQ_PEND and the value returned by schedule_timeout() is the same as the original timeout (HCI_INIT_TIMEOUT on a system with HZ=1000). Use wait_event_interruptible_timeout() instead of open-coding similar behaviour which is subject to the spurious failure described above. Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Showing
Please register or sign in to comment