summaryrefslogtreecommitdiffstats
path: root/scripts/basic
diff options
context:
space:
mode:
authorJohn Keeping <john@metanate.com>2018-04-19 16:29:37 +0100
committerMarcel Holtmann <marcel@holtmann.org>2018-05-18 06:37:51 +0200
commit67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2 (patch)
tree5e9713807bf76fcc72ff48be5144f81edab6b365 /scripts/basic
parentee6493462f74013c6f365429401b716500aff838 (diff)
downloadlinux-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