BMC/Intel-BMC/linux.git/net/bluetooth/hci_event.c, branch dev

Bluetooth: Remove redundant check for ACL_LINK

2015-06-12T10:07:20+00:00

The encryption key size is read only for BR/EDR (ACL_LINK) connections so there's no need to check for it in the read_enc_key_size_complete() callback. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Read encryption key size for BR/EDR connections

2015-06-12T09:38:45+00:00

Since Bluetooth 3.0 there's a HCI command available for reading the encryption key size of an BR/EDR connection. This information is essential e.g. for generating an LTK using SMP over BR/EDR, so store it as part of struct hci_conn. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Move SC-only check outside of BT_CONFIG branch

2015-06-12T09:38:45+00:00

Checking for SC-only mode requirements when we get an encrypt change event shouldn't be limited to the BT_CONFIG state but done any time encryption changes. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Fix encryption key size handling for LTKs

2015-06-09T07:09:06+00:00

The encryption key size for LTKs is supposed to be applied only at the moment of encryption. When generating a Link Key (using LE SC) from the LTK the full non-shortened value should be used. This patch modifies the code to always keep the full value around and only apply the key size when passing the value to HCI. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Read LE remote features during connection establishment

2015-04-09T05:36:54+00:00

When establishing a Bluetooth LE connection, read the remote used features mask to determine which features are supported. This was not really needed with Bluetooth 4.0, but since Bluetooth 4.1 and also 4.2 have introduced new optional features, this becomes more important. This works the same as with BR/EDR where the connection enters the BT_CONFIG stage and hci_connect_cfm call is delayed until the remote features have been retrieved. Only after successfully receiving the remote features, the connection enters the BT_CONNECTED state. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Convert local OOB data reading to use HCI request

2015-04-02T14:09:29+00:00

Now that there's a HCI request API available where the callback receives the resulting skb, we can convert the local OOB data reading to use this new API. This patch does the necessary update in mgmt.c (which also requires moving the callback higher up since it's now a static function) and removes the custom calls from hci_event.c that are no-longer necessary. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Move hci_get_cmd_complete() to hci_event.c

2015-04-02T14:09:28+00:00

To make the hci_req_run_skb() API consistent with hci_cmd_sync_ev() the callback should receive the cmd_complete parameters in the 'normal' case and the full HCI event if a special event was expected. This patch moves the hci_get_cmd_complete() function from hci_core.c to hci_event.c where it's used to strip the skb from the needed headers before passing it on to the callback. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Remove unneeded recv_event variable

2015-04-02T14:09:27+00:00

Now that the synchronous HCI requests use the new API and a new private variable the recv_evt member of hci_dev is no-longer needed. This patch removes it. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Add second hci_request callback option for full skb

2015-04-02T14:09:27+00:00

This patch adds a second possible callback for HCI requests where the callback will receive the full skb of the last successfully completed HCI command. This API is useful for cases where we want to use a request to read some data and the existing hci_event.c handlers do not store it e.g. in the hci_dev struct. The reason the patch is a bit bigger than just adding the new API is because the hci_req_cmd_complete() functions required some refactoring to enable it: now hci_req_cmd_complete() is simply used to request the callback pointers if any, and the actual calling of them happens from a single place at the end of hci_event_packet(). The reason for this is that we need to pass the original skb (without any skb_pull, etc modifications done to it) and it's simplest to keep track of it within the hci_event_packet() function. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Add clarifying comment to command status handling

2015-04-02T14:09:27+00:00

When dealing with HCI command status events, the reasoning for trying to mark a request as complete if no specific event is being waited for and status was success is not self-evident. This patch adds a clarifying comment above the if-statement. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann