diff options
author | John Keeping <john@metanate.com> | 2018-04-19 16:29:37 +0100 |
---|---|---|
committer | Marcel Holtmann <marcel@holtmann.org> | 2018-05-18 06:37:51 +0200 |
commit | 67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2 (patch) | |
tree | 5e9713807bf76fcc72ff48be5144f81edab6b365 /scripts/basic | |
parent | ee6493462f74013c6f365429401b716500aff838 (diff) | |
download | linux-67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2.tar.bz2 |
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 'scripts/basic')
0 files changed, 0 insertions, 0 deletions