diff options
| author | John Keeping | 2018-04-19 17:29:37 +0200 |
|---|---|---|
| committer | Marcel Holtmann | 2018-05-18 06:37:51 +0200 |
| commit | 67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2 (patch) | |
| tree | 5e9713807bf76fcc72ff48be5144f81edab6b365 /drivers/bluetooth/btusb.c | |
| parent | Bluetooth: Prevent buffer overflow for large advertisement data (diff) | |
| download | kernel-qcow2-linux-67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2.tar.gz kernel-qcow2-linux-67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2.tar.xz kernel-qcow2-linux-67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2.zip | |
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>
Diffstat (limited to 'drivers/bluetooth/btusb.c')
0 files changed, 0 insertions, 0 deletions