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>
Bluetooth: Change default MTU for L2CAP ATT channel

This patch changes the default MTU value for L2CAP ATT fixed channel
to L2CAP_DEFAULT_MTU.

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
minimum MTU value must not be less than 23 octets [1].

Up to L2CAP, in ATT protocol level, we have the ATT_MTU which defines
the maximum size of any ATT message sent between client and server. A
higher layer specification defines its default value. GATT spec defines
default ATT_MTU to 23 octets. If antoher GATT profile wants to use a
greater value of ATT_MTU (e.g. HID over GATT profile) it should
negotiate a new value of by executing the GATT Exchange MTU procedure
[2].

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

[1] - Core spec, Vol 3, Part A, 5.1
[2] - Core spec, Vol 3, Part G, 4.3.1

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

If user tries to set a invalid MTU value, l2cap_sock_setsockopt_old
shoudl return -EINVAL.

A helper function was created to check if a given mtu value is valid
according to the channel constrains.

Signed-off-by: Andre Guedes <aguedespe@gmail.com>
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 <aguedespe@gmail.com>
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 <aguedespe@gmail.com>