Bluetooth: Allow only one LE connection attempt

Only one outgoing LE connection attempt should be possible.
hci_connect() will now return -EBUSY in case there's another pending
outgoing connection.

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Return proper mgmt state when LE pairing connection failed

MGMT_STATUS_BUSY should be returned when LE pairing cannot be started due
to another outgoing connection attempt is ongoing.

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Fix not removing hci_conn for failed LE connection

This patch changes way LE Connection Complete event with error status are
handled. BDADDR returned in such event packet do not need to be valid and
should not be used to search for existing hci_conn. Instead, any hci_conn
with BT_CONNECT state should be matched since there can be only one
pending LE outgoing connection at any time.

If not handled properly, appriopriate hci_conn will not be removed and
subsequent connection to given peer will try to reuse it without making
actual connection attempt.

2012-05-07 11:21:39.133378 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
    bdaddr 00:22:D0:10:13:EE type 1
2012-05-07 11:21:39.138774 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2012-05-07 11:21:44.752854 < HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0
2012-05-07 11:21:44.759475 > HCI Event: Command Complete (0x0e) plen 4
    LE Create Connection Cancel (0x08|0x000e) ncmd 1
2012-05-07 11:21:44.764479 > HCI Event: LE Meta Event (0x3e) plen 19
    LE Connection Complete
      status 0x02 handle 0, role master
      bdaddr 00:00:00:00:00:00 (Public)

[14898.739425] [6603] hci_connect: hci0 dst 00:22:D0:10:13:EE
[14898.739429] [6603] hci_conn_add: hci0 dst 00:22:D0:10:13:EE
[14898.739434] [6603] hci_conn_init_sysfs: conn ffff880079f03000
[14898.739440] [6603] hci_send_cmd: hci0 opcode 0x200d plen 25
[14898.739443] [6603] hci_send_cmd: skb len 28
[14898.739487] [6603] hci_chan_create: hci0 conn ffff880079f03000
...
[14938.860231] [55] hci_send_cmd: hci0 opcode 0x200e plen 0
...
[14938.876427] [55] hci_le_conn_complete_evt: hci0 status 2
[14938.876433] [55] hci_conn_add: hci0 dst 00:00:00:00:00:00
[14938.876439] [55] hci_conn_init_sysfs: conn ffff88007aeff800
[14938.876454] [55] hci_send_to_control: len 14
[14938.876470] [55] l2cap_connect_cfm: hcon ffff88007aeff800 bdaddr 00:00:00:00:00:00 status 2
[14938.876474] [55] hci_conn_del: hci0 conn ffff88007aeff800 handle 0

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Acked-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Enable duplicate filtering in le scan

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Use GFP_KERNEL in mgmt_handlers

add_uuid and get_connections mgmt_handlers don't hold spinlock anymore
and they are executed by user threads running in kernel-mode. Thus, we
should use GFP_KERNEL for memory allocation instead of GFP_ATOMIC.

Signed-off-by: Andre Guedes <aguedespe@gmail.com>
Bluetooth: Use GFP_KERNEL in mgmt_pending_add

We are allowed to sleep in mgmt_pending_add, so we should use
GFP_KERNEL for memory allocations.

Signed-off-by: Andre Guedes <aguedespe@gmail.com>
Bluetooth: Use GFP_KERNEL in mgmt events functions

cmd_status, cmd_complete and mgmt_event functions are executed in
process context and they are not called inside atomic sections. Thus,
they should use GFP_KERNEL for memory allocation instead of GFP_ATOMIC.

Signed-off-by: Andre Guedes <aguedespe@gmail.com>
Bluetooth: Process unpair command if connect failed

Signed-off-by: Jefferson Delfes <jefferson.delfes@openbossa.org>
Bluetooth: Change default MTU for L2CAP ATT channel

This patch changes the default MTU value for L2CAP ATT fixed channel
to L2CAP_DEFAULT_MTU (672 octets).

Differently from others L2CAP channels, in L2CAP ATT fixed channel
there is no MTU negotiation. The MTU value for that channel is up to
the L2CAP implementation. The only restriction in L2CAP spec is the
MTU value must not be less than 23 octets.

At ATT protocol level (on top of L2CAP), we have the ATT_MTU which
defines the maximum size of any ATT message sent between client and
server. GATT profile defines ATT_MTU default value to 23 octets. If
a GATT based profile wants to use ATT_MTU greater than 23 octets
(e.g. HID over GATT profile), it should negotiate a new value by
executing the GATT Exchange MTU sub-procedure.

Thus, in order to support any value of ATT_MTU negotiated at ATT
protocol level, our L2CAP implementation should have L2CAP ATT
fixed channel MTU equal or greater than ATT_MAX_MTU (512 octets).

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Check MTU value in l2cap_sock_setsockopt_old

If user tries to set an invalid MTU value, l2cap_sock_setsockopt_old
should return -EINVAL.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Rename L2CAP_LE_DEFAULT_MTU

This patch renames L2CAP_LE_DEFAULT_MTU macro to L2CAP_LE_MIN_MTU
since it represents the minimum MTU value, not the default MTU
value for LE.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Trivial refactoring in __l2cap_chan_add

All cases in switch statement set chan->omtu to L2CAP_DEFAULT_MTU.
This patch moves the assigments to outside the switch statement.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Bluetooth: Set MTU in l2cap_chan_set_defaults

Set the default values for imtu and omtu in l2cap_chan_set_defaults
helper function. This way, imtu and omtu default values are set
together with others L2CAP channel parameters.

This patch also removes imtu and omtu initialization from l2cap_sock_
init since they are now initialized in l2cap_chan_set_defaults.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
HID: User-space I/O driver support for HID subsystem

This driver allows to write I/O drivers in user-space and feed the input
into the HID subsystem. It operates on the same level as USB-HID and
Bluetooth-HID (HIDP). It does not provide support to write special HID
device drivers but rather provides support for user-space I/O devices to
feed their data into the kernel HID subsystem. The HID subsystem then
loads the HID device drivers for the device and provides input-devices
based on the user-space HID I/O device.

This driver register a new char-device (/dev/uhid). A user-space process
has to open this file for each device that it wants to provide to the
kernel. It can then use write/read to communicate with the UHID driver.
Both input and output data is sent with a uhid_event structure. The "type"
field of the structure specifies what kind of event is sent. There is a
file in Documentation/hid/ explaining the ABI and an example user-space
program that uses this interface in samples/uhid/.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>