Bluetooth: Fix getting SCO socket options in deferred state
authorJohan Hedberg <johan.hedberg@intel.com>
Thu, 8 Aug 2013 11:53:56 +0000 (14:53 +0300)
committerGustavo Padovan <gustavo.padovan@collabora.co.uk>
Wed, 21 Aug 2013 14:47:04 +0000 (16:47 +0200)
commit9d225d2208a6f17da5987ff4e7710b9e805cb5d6
treece01f5033eb9f4592e2e05f307d5eedc1b42fd6f
parentba34dd3df73eaa2aa4fbb82a91aade3f3a910acb
Bluetooth: Fix getting SCO socket options in deferred state

When a socket is in deferred state there does actually exist an
underlying connection even though the connection state is not yet
BT_CONNECTED. In the deferred state it should therefore be allowed to
get socket options that usually depend on a connection, such as
SCO_OPTIONS and SCO_CONNINFO.

This patch fixes the behavior of some user space code that behaves as
follows without it:

$ sudo tools/btiotest -i 00:1B:DC:xx:xx:xx -d -s
accept=2 reject=-1 discon=-1 defer=1 sec=0 update_sec=0 prio=0 voice=0x0000
Listening for SCO connections
bt_io_get(OPT_DEST): getsockopt(SCO_OPTIONS): Transport endpoint is not connected (107)
Accepting connection
Successfully connected to 60:D8:19:xx:xx:xx. handle=43, class=000000

The conditions that the patch updates the if-statements to is taken from
similar code in l2cap_sock.c which correctly handles the deferred state.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
net/bluetooth/sco.c