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

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem

2011-07-15T14:05:24Z

Conflicts: net/bluetooth/l2cap_core.c

Bluetooth: Fixes l2cap "command reject" reply according to spec

2011-07-11T04:43:25Z

There can 3 reasons for the "command reject" reply produced by the stack. Each such reply should be accompanied by the relevand data ( as defined in spec. ). Currently there is one instance of "command reject" reply with reason "invalid cid" wich is fixed. Also, added clean-up definitions related to the "command reject" replies. Signed-off-by: Ilia Kolomisnky Signed-off-by: Gustavo F. Padovan

Bluetooth: Add support for returning the encryption key size

2011-07-08T21:39:31Z

This will be useful when userspace wants to restrict some kinds of operations based on the length of the key size used to encrypt the link. Signed-off-by: Vinicius Costa Gomes Signed-off-by: Gustavo F. Padovan

Bluetooth: Add support for storing the key size

2011-07-08T21:39:19Z

In some cases it will be useful having the key size used for encrypting the link. For example, some profiles may restrict some operations depending on the key length. The key size is stored in the key that is passed to userspace using the pin_length field in the key structure. For now this field is only valid for LE controllers. 3.0+HS controllers define the Read Encryption Key Size command, this field is intended for storing the value returned by that command. Signed-off-by: Vinicius Costa Gomes Signed-off-by: Gustavo F. Padovan

Bluetooth: Remove unused field in hci_conn

2011-07-08T20:37:22Z

Signed-off-by: Vinicius Costa Gomes Signed-off-by: Gustavo F. Padovan

Bluetooth: Add functions to manipulate the link key list for SMP

2011-07-08T20:36:31Z

As the LTK (the new type of key being handled now) has more data associated with it, we need to store this extra data and retrieve the keys based on that data. Methods for searching for a key and for adding a new LTK are introduced here. Signed-off-by: Vinicius Costa Gomes Signed-off-by: Gustavo F. Padovan

Bluetooth: Add new structures for supporting SM key distribution

2011-07-08T20:36:25Z

We need these changes because SMP keys may have more information associated with them, for example, in the LTK case, it has an encrypted diversifier (ediv) and a random number (rand). Signed-off-by: Vinicius Costa Gomes Signed-off-by: Gustavo F. Padovan

Bluetooth: Add support for SMP phase 3 (key distribution)

2011-07-08T20:07:43Z

This adds support for generating and distributing all the keys specified in the third phase of SMP. This will make possible to re-establish secure connections, resolve private addresses and sign commands. For now, the values generated are random. Signed-off-by: Vinicius Costa Gomes Signed-off-by: Gustavo F. Padovan

Bluetooth: Remove L2CAP busy queue

2011-07-07T18:29:06Z

The ERTM receive buffer is now handled in a way that does not require the busy queue and the associated polling code. Signed-off-by: Mat Martineau Signed-off-by: Gustavo F. Padovan

Bluetooth: Use event-driven approach for handling ERTM receive buffer

2011-07-07T18:28:56Z

This change moves most L2CAP ERTM receive buffer handling out of the L2CAP core and in to the socket code. It's up to the higher layer (the socket code, in this case) to tell the core when its buffer is full or has space available. The recv op should always accept incoming ERTM data or else the connection will go down. Within the socket layer, an skb that does not fit in the socket receive buffer will be temporarily stored. When the socket is read from, that skb will be placed in the receive buffer if possible. Once adequate buffer space becomes available, the L2CAP core is informed and the ERTM local busy state is cleared. Receive buffer management for non-ERTM modes is unchanged. Signed-off-by: Mat Martineau Signed-off-by: Gustavo F. Padovan