linux/include/net/bluetooth, branch v3.17

Bluetooth: Fix hci_conn reference counting for auto-connections

2014-08-20T18:57:39Z

Recently the LE passive scanning and auto-connections feature was introduced. It uses the hci_connect_le() API which returns a hci_conn along with a reference count to that object. All previous users would tie this returned reference to some existing object, such as an L2CAP channel, and there'd be no leaked references this way. For auto-connections however the reference was returned but not stored anywhere, leaving established connections with one higher reference count than they should have. Instead of playing special tricks with hci_conn_hold/drop this patch associates the returned reference from hci_connect_le() with the object that in practice does own this reference, i.e. the hci_conn_params struct that caused us to initiate a connection in the first place. Once the connection is established or fails to establish this reference is removed appropriately. One extra thing needed is to call hci_pend_le_actions_clear() before calling hci_conn_hash_flush() so that the reference is cleared before the hci_conn objects are fully removed. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Rename pairable mgmt setting to bondable

2014-07-30T17:28:41Z

This setting maps to the HCI_BONDABLE flag which tracks whether we're bondable or not. Therefore, rename the mgmt setting and respective command accordingly. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Rename HCI_PAIRABLE to HCI_BONDABLE

2014-07-30T17:28:41Z

The HCI_PAIRABLE flag isn't actually controlling whether we're pairable but whether we're bondable. Therefore, rename it accordingly. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Provide defaults for LE advertising interval

2014-07-26T17:05:09Z

Store the default values for minimum and maximum advertising interval with all the other controller defaults. These vaules are sent to the adapter whenever advertising is (re)enabled. Signed-off-by: Georg Lukas Signed-off-by: Marcel Holtmann

Bluetooth: Fix issue with ADV_IND reports and auto-connection handling

2014-07-23T21:37:23Z

When adding remote devices to the kernel using the Add Device management command, these devices are explicitly allowed to connect. This kind of incoming connections are possible even when the controller itself is not connectable. For BR/EDR this distinction is pretty simple since there is only one type of incoming connections. With LE this is not that simple anymore since there are ADV_IND and ADV_DIRECT_IND advertising events. The ADV_DIRECT_IND advertising events are send for incoming (slave initiated) connections only. And this is the only thing the kernel should allow when adding devices using action 0x01. This meaning of incoming connections is coming from BR/EDR and needs to be mapped to LE the same way. Supporting the auto-connection of devices using ADV_IND advertising events is an important feature as well. However it does not map to incoming connections. So introduce a new action 0x02 that allows the kernel to connect to devices using ADV_DIRECT_IND and in addition ADV_IND advertising reports. This difference is represented by the new HCI_AUTO_CONN_DIRECT value for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Get MWS transport configuration of the controller

2014-07-23T17:34:08Z

If the Bluetooth controller supports Get MWS Transport Layer Configuration command, then issue it during initialization. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Read list of local codecs supported by the controller

2014-07-23T17:34:06Z

If the Bluetooth controller supports Read Local Supported Codecs command, then issue it during initialization so that the list of codecs is known. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Introduce a flag to track who really initiates authentication

2014-07-17T12:39:40Z

Even though our side requests authentication, the original action that caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM connect request. To track this information introduce a new hci_conn flag called HCI_CONN_AUTH_INITIATOR. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Pass initiator/acceptor information to hci_conn_security()

2014-07-17T12:39:39Z

We're interested in whether an authentication request is because of a remote or local action. So far hci_conn_security() has been used both for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect requests) so without some modifications it cannot know which peer is responsible for requesting authentication. This patch adds a new "bool initiator" parameter to hci_conn_security() to indicate which side is responsible for the request and updates the current users to pass this information correspondingly. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Track number of LE slave connections

2014-07-16T09:58:03Z

Most (probably all) controllers can only deal with a single slave LE connection at a time. This patch adds a counter for such connections so that the number can be quickly looked up without iterating the connections list. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann