Bluetooth: use wait_event API instead of open-coding it
authorJohn Keeping <john@metanate.com>
Thu, 19 Apr 2018 15:29:37 +0000 (16:29 +0100)
committerMarcel Holtmann <marcel@holtmann.org>
Fri, 18 May 2018 04:37:51 +0000 (06:37 +0200)
commit67d8cee432f5564bba3fe9e0d8b1f07c3e41dda2
tree5e9713807bf76fcc72ff48be5144f81edab6b365
parentee6493462f74013c6f365429401b716500aff838
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>
net/bluetooth/hci_request.c