Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

For the workqueue creation interfaces that do not expect format strings,
make sure they cannot accidently be parsed that way.  Additionally, clean
up calls made with a single parameter that would be handled as a format
string.  Many callers are passing potentially dynamic string content, so
use "%s" in those cases to avoid any potential accidents.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some Bluetooth controllers doesn't support this command so we first
need to check for its support before sending it. This patch adds a
lengthful commentary about this.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The length check is invalid since the length varies with type of
info response.

This was introduced by the commit cb3b3152

Because of this, l2cap info rsp is not handled and command reject is sent.

> ACL data: handle 11 flags 0x02 dlen 16
        L2CAP(s): Info rsp: type 2 result 0
          Extended feature mask 0x00b8
            Enhanced Retransmission mode
            Streaming mode
            FCS Option
            Fixed Channels
< ACL data: handle 11 flags 0x00 dlen 10
        L2CAP(s): Command rej: reason 0
          Command not understood

Cc: stable@vger.kernel.org
Signed-off-by: NJaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: NChan-Yeol Park <chanyeol.park@samsung.com>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

For NULL terminated string, need always let it ended by zero.

Since have already called memcpy() to initialize 'ci', so need not
redundant initialization.

Better use ''if(session->hid) {} else if(session->input) {}"" instead
of ''if(session->hid) {}; if(session->input) {};''
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Remove HCI_LINK_KEYS flag since using HCI_MGMT is enough for test that
user space expects the kernel managing link keys.
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Use HCI_MGMT flag instead of HCI_LINK_KEYS flag. There is a problem with
HCI_LINK_KEYS flag since it is set only when link keys are loaded. Otherwise
kernel assumes that old interface is used.
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

We only want to send Mgmt Device Found Events if we are running the
Device Discovery procedure (started by the MGMT Start Discovery
Command). Inquiry or LE scanning triggered by HCI raw interface (e.g.
hcitool) or kernel internals should not send Mgmt Device Found Events.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch removes the hci_cc_le_set_scan_param event handler. This
handler became empty because failures of this event are now handled
by start_discovery_complete function in mgmt.c.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch removes hci_do_inquiry and hci_cancel_inquiry helpers. We
now use the HCI request framework in device discovery functionality
and these helpers are no longer needed.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch removes the LE scan helpers hci_le_scan and hci_cancel_
le_scan and all code related to it. We now use the HCI request
framework in device discovery functionality and these helpers are
no longer needed.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch does a trivial refactoring in hci_cc_le_set_scan_enable.
Since start and stop discovery command failures are now handled in
mgmt layer, the status check became empty. So, we can move it to
outside the switch statement.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

mgmt_stop_discovery_failed is now only used in mgmt.c so we can
make it a local function. This patch also moves the mgmt_stop_
discovery_failed definition up in mgmt.c to avoid forward
declaration.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Since all mgmt stop discovery command complete events are now handled
in stop_discovery_complete callback in mgmt.c, we can remove this
handling from hci_event.c.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch modifies the stop_discovery function so it uses the HCI
request framework.

The HCI request is built according to the current discovery state
(inquiry, LE scanning or name resolving) and a complete callback is
register to handle the command complete event for the stop discovery
command. This way, we move all stop_discovery mgmt handling code
spread in hci_event.c to a single place in mgmt.c.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In order to have a better HCI error handling in interleaved discovery
functionality, we should use the HCI request framework.

This patch updates le_scan_disable_work function so it uses the
HCI request framework instead of the hci_send_cmd helper. A complete
callback is registered (le_scan_disable_work_complete function) so we
are able to trigger the inquiry procedure (if we are running the
interleaved discovery) or to stop the discovery procedure (if we are
running LE-only discovery).

This patch also removes the extra logic in hci_cc_le_set_scan_enable
to trigger the inquiry procedure and the mgmt_interleaved_discovery
function since they become useless.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Some of discovery macros will be used in hci_core so we need to
define them in common place such as hci_core.h. Thus, this patch
moves discovery macros to hci_core.h and also adds the DISCOV_
prefix to them.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

mgmt_start_discovery_failed is now only used in mgmt.c so we can
make it a local function. This patch also moves the mgmt_start_
discovery_failed definition up in mgmt.c to avoid forward
declaration.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Since all mgmt start discovery command complete events are now handled
in start_discovery_complete callback in mgmt.c, we can remove this
handling from hci_event.c.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch modifies the start_discovery function so it uses the HCI
request framework.

We build the HCI request according to the discovery type (add inquiry
or LE scan HCI commands) and run the HCI request. We also register
the start_discovery_complete callback which handles mgmt command
complete events for this command. This way, we move all start_
discovery mgmt handling code spread in hci_event.c to a single place
in mgmt.c.

This patch also merges the LE-only and interleaved discovery type
cases since these cases are pretty much the same now.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In order to use HCI request framework in start_discovery, we'll need
to call inquiry_cache_flush in mgmt.c. Therefore, this patch adds the
hci_ prefix to inquiry_cache_flush and makes it non-static.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The LE ATT server socket needs to be superseded by any ATT client
sockets. Previously this was done by looking at the hcon->out variable
(indicating whether the connection is outgoing or incoming) which is a
too crude way of determining whether the server socket needs to be
picked or not (an outgoing connection doesn't necessarily mean that an
ATT client socket has triggered it).

This patch extends the ATT server socket lookup function
(l2cap_le_conn_ready) to be used for all LE connections (regardless of
the hcon->out value) and adds an internal check into the function for
the existence of any ATT client sockets (in which case the server socket
should be skipped). For this to work reliably all lookups must be done
while the l2cap_conn->chan_lock is held, meaning also that the call to
l2cap_chan_add needs to be changed to its lockless __l2cap_chan_add
counterpart.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

There's no need to reset disc_timeout in l2cap_le_conn_ready since
HCI_DISCONN_TIMEOUT is the default when the hci_conn is created and
there should be no way for it to get changed between creation and
l2cap_le_conn_ready being called.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The L2CAP code has been incrementing the hci_conn reference for each
l2cap_chan instance in the l2cap_conn list. Likewise, the reference is
dropped each time an l2cap_chan is removed from the list. The reference
counting policy with respect to removal has been clear and explicit in
the l2cap_chan_del function, however for addition the function
calling 2cap_chan_add has always had to do a separate hci_conn_hold
call.

What made the counting even more hard to follow is that the
hci_connect() procedure increments the reference and the L2CAP layer
making this call took advantage of it to use it as its own reference.

This patch aims to clarify things by having the call to hci_conn_hold
inside __l2cap_chan_add, thereby removing the need to do it in the
functions calling __l2cap_chan_add. The reference count for hci_connect
is still kept as it's necessary for users such as mgmt_pair_device,
however for the L2CAP layer it means that an extra call to hci_conn_drop
must be performed once l2cap_chan_add has been done.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In l2cap_att_channel() we're only interested in the BT_CONNECTED state
so this state can directly be passed to l2cap_global_chan_by_scid().
This way there's no need to do any additional state check later.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The sk variable is of quite little use since it's only used to simplify
access in the two bt_sk() calls.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In l2cap_le_conn_ready() after doing l2cap_chann_add() the LE channel is
part of the list which is subsequently iterated in l2cap_conn_ready() in
this loop each channel will get l2cap_chan_ready() called which would
result in trying to set the channel two times into BT_CONNECTED state.
Instead it makes sense to just add the channel but not call chan_ready
in l2cap_le_conn_ready, which is what this patch does.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

There is an extra call to smp_conn_security() for outgoing LE
connections from l2cap_conn_ready() but the reason for this call is far
from clear. After a bit of commit history research and using git blame I
found out that this extra call is for socket-less pairing processes
added by commit 160dc6ac. This patch adds a clarifying comment to the
code for this.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Since in the future more than the ATT CID may be permissible we should
not be hardcoding it for all LE connections in __l2cap_chan_add().
Instead, the source ATT CID should only be set if the destination is
also ATT, and in other cases we should just use the existing dynamic CID
allocation function.

Assigning scid based on dcid means that whenever __l2cap_chan_add() is
called that chan->dcid is properly initialized. l2cap_le_conn_ready()
wasn't initializing is properly so this is also taken care of in this
patch.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The current test in l2cap_chan_connect is intended to protect against
multiple conflicting connect attempts. However, it assumes that there
will ever only be a single CID that is connected to, which is not true.
We do need to check for conflicts with connect attempts to the same
destination CID but this check is not in anyway specific to LE but can
be applied to BR/EDR as well.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The choice between LE and BR/EDR should be made on the destination
address type instead of the destination CID. This is particularly
important when in the future more than one CID will be allowed for LE.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In future Core Specification versions the ATT CID will be just one of
many possible CIDs that can be used for data transfer. Therefore, it
makes sense to rename the define for the ATT CID to something less
ambigous.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The LE L2CAP signalling channel follows its own rules and will continue
to evolve independently from the BR/EDR signalling channel. Therefore,
it makes sense to have a clear split from BR/EDR by having a dedicated
function for handling LE signalling commands.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Even though the HCI_Delete_Stored_Link_Key command is mandatory for 1.1
and later controllers some controllers do not seem to support it
properly as was witnessed by one Broadcom based controller:

< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
    bdaddr 00:00:00:00:00:00 all 1
> HCI Event: Command Complete (0x0e) plen 4
    Delete Stored Link Key (0x03|0x0012) ncmd 1
    status 0x11 deleted 0
    Error: Unsupported Feature or Parameter Value

Luckily this same controller also doesn't list the command in its
supported commands bit mask (counting from 0 bit 7 of octet 6):

< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Complete (0x0e) plen 68
    Read Local Supported Commands (0x04|0x0002) ncmd 1
    status 0x00
    Commands: ffffffffffff1ffffffffffff30fffff3f

Therefore, it makes sense to move sending of HCI_Delete_Stored_Link_Key
to after receiving the supported commands response and to only send it
if its respective bit in the mask is set. The downside of this is that
we no longer send the HCI_Delete_Stored_Link_Key command for Bluetooth
1.1 controllers since HCI_Read_Local_Supported_Command was introduced in
version 1.2, but this is an acceptable penalty as the command in
question shouldn't affect critical behavior.
Reported-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Tested-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
controller, memory corruption happens due to a memcpy() call with
negative length.

Fix this crash on either incoming or outgoing connections with a MTU
smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:

[   46.885433] BUG: unable to handle kernel paging request at f56ad000
[   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
[   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
[   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
[   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
[   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
[   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
[   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
[   46.888037] EIP is at memcpy+0x1d/0x40
[   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
[   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
[   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
[   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[   46.888037] DR6: ffff0ff0 DR7: 00000400
[   46.888037] Stack:
[   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
[   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
[   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
[   46.888037] Call Trace:
[   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
[   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
[   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
[   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
[   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
[   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
[   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
[   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
[   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
[   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
[   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
[   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
[   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
[   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
[   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
[   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
[   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
[   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
[   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
[   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
[   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
[   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
[   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
[   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
[   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
[   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
[   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
[   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
[   46.888037] CR2: 00000000f56ad000
[   46.888037] ---[ end trace 0217c1f4d78714a9 ]---
Signed-off-by: NAnderson Lizardo <anderson.lizardo@openbossa.org>
Cc: stable@vger.kernel.org
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If hci_dev_open fails we need to ensure that the corresponding
mgmt_set_powered command gets an appropriate response. This patch fixes
the missing response by adding a new mgmt_set_powered_failed function
that's used to indicate a power on failure to mgmt. Since a situation
with the device being rfkilled may require special handling in user
space the patch uses a new dedicated mgmt status code for this.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There has been code in place to check that the L2CAP length header
matches the amount of data received, but many PDU handlers have not been
checking that the data received actually matches that expected by the
specific PDU. This patch adds passing the length header to the specific
handler functions and ensures that those functions fail cleanly in the
case of an incorrect amount of data.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

LE-only controllers do not support extended features so any kind of host
feature bit checks do not make sense for them. This patch fixes code
used for both single-mode (LE-only) and dual-mode (BR/EDR/LE) to use the
HCI_LE_ENABLED flag instead of the "Host LE supported" feature bit for
LE support tests.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While l2cap_user callbacks are running, the whole hci_dev is locked. Even
if we would add more fine-grained locking to HCI core, it would still be
called from the non-reentrant rx work-queue and thus block the event
processing.

However, if we want to perform synchronous I/O during HID device
registration (eg., to perform device-detection), we need the HCI core
to be able to dispatch incoming data.

Therefore, we now move device-registration to a separate worker. The HCI
core can continue running and we add devices asynchronously in another
kernel thread. Device removal is synchronized and waits for the worker
to exit before calling the usual device removal functions.

If l2cap_user->remove is called before the thread registered the devices,
we set "terminate" to true and the thread will skip it. If
l2cap_user->remove is called after it, we notice this as the device
is no longer in HIDP_SESSION_PREPARING state and simply unregister the
device as we did before.
There is no new deadlock as we now call hidp_session_add_dev() with
one lock less held (the HCI lock) and it cannot itself call back into
HCI as it was called with the HCI-lock held before.

One might wonder whether this can block during device unregistration.
But we set "terminate" to true and wake the HIDP thread up _before_
unregistering the HID/input devices. Therefore, all pending HID I/O
operations are canceled. All further I/O attempts will fail with ENODEV
or EIO. So all latency we can get are few context-switches, but no
timeouts or blocking I/O waits!

This change also prepares for a long standing HID bug. All HID devices
that register power_supply devices need to be able to handle callbacks
during registration (a power_supply oddity that cannot easily be fixed).
So with this patch available, we can allow HID I/O during registration
by calling the recently introduced hid_device_io_start/stop helpers,
which currently are a no-op for bluetooth due to this locking.

Note that we cannot do the same for input devices. input-core doesn't
allow us to call input_event() asynchronously to input_register_device(),
which HID-core kindly allows (for good reasons).
Fixing input-core to allow this isn't as easy as it sounds and is,
beside simplifying HIDP, not really an improvement. Hence, we still
register input devices synchronously as we did before. Only HID devices
are registered asynchronously.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Tested-by: NDaniel Nicoletti <dantti12@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The CID is fixed to L2CAP ATT channel and so there is no need to hand it
down to the handling function. Just use a constant instead.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>