In case of a Low Energy only controller it makes no sense to configure
the full BR/EDR event mask. It will just enable events that can not be
send anyway and there is no guarantee that such a controller will accept
this value.

Use event mask 0x90 0xe8 0x04 0x02 0x00 0x80 0x00 0x20 for LE-only
controllers which enables the following events:

          Disconnection Complete
          Encryption Change
          Read Remote Version Information Complete
          Command Complete
          Command Status
          Hardware Error
          Number of Completed Packets
          Data Buffer Overflow
          Encryption Key Refresh Complete
          LE Meta

This is according to Core Specification, Part E, Section 3.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In certain circumstances, such as an HCI driver using __hci_cmd_sync_ev
with HCI_EV_CMD_COMPLETE as the expected completion event there is the
chance that hci_event_packet will call hci_req_cmd_complete twice (once
for the explicitly looked after event and another time in the actual
handler of cmd_complete).

In the case of __hci_cmd_sync_ev this introduces a race where the first
call wakes up the blocking __hci_cmd_sync_ev and lets it complete.
However, by the time that a second __hci_cmd_sync_ev call is already in
progress the second hci_req_cmd_complete call (from the previous
operation) will wake up the blocking function prematurely and cause it
to fail, as witnessed by the following log:

[  639.232195] hci_rx_work: hci0 Event packet
[  639.232201] hci_req_cmd_complete: opcode 0xfc8e status 0x00
[  639.232205] hci_sent_cmd_data: hci0 opcode 0xfc8e
[  639.232210] hci_req_sync_complete: hci0 result 0x00
[  639.232220] hci_cmd_complete_evt: hci0 opcode 0xfc8e
[  639.232225] hci_req_cmd_complete: opcode 0xfc8e status 0x00
[  639.232228] __hci_cmd_sync_ev: hci0 end: err 0
[  639.232234] __hci_cmd_sync_ev: hci0
[  639.232238] hci_req_add_ev: hci0 opcode 0xfc8e plen 250
[  639.232242] hci_prepare_cmd: skb len 253
[  639.232246] hci_req_run: length 1
[  639.232250] hci_sent_cmd_data: hci0 opcode 0xfc8e
[  639.232255] hci_req_sync_complete: hci0 result 0x00
[  639.232266] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1
[  639.232271] __hci_cmd_sync_ev: hci0 end: err 0
[  639.232276] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-61)
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>

None of the BlueFRITZ! devices with manufacurer ID 31 (AVM Berlin)
support HCI_Read_Local_Supported_Commands. It is safe to use the
manufacturer ID (instead of e.g. a USB ID specific quirk) because the
company never created any newer controllers.

< HCI Command: Read Local Supported Comm.. (0x04|0x0002) plen 0 [hci0] 0.210014
> HCI Event: Command Status (0x0f) plen 4 [hci0] 0.217361
      Read Local Supported Commands (0x04|0x0002) ncmd 1
        Status: Unknown HCI Command (0x01)
Reported-by: NJörg Esser <jackfritt@boh.de>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Tested-by: NJörg Esser <jackfritt@boh.de>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

If hci_dev_open() is called after hci_register_dev() added the device to
the hci_dev_list but before the workqueue are created we could run into a
NULL pointer dereference (see below).

This bug is very unlikely to happen, systems using bluetoothd to
manage their bluetooth devices will never see this happen.

BUG: unable to handle kernel NULL pointer dereference
0100
IP: [<ffffffff81077502>] __queue_work+0x32/0x3d0
(...)
Call Trace:
 [<ffffffff81077be5>] queue_work_on+0x45/0x50
 [<ffffffffa016e8ff>] hci_req_run+0xbf/0xf0 [bluetooth]
 [<ffffffffa01709b0>] ? hci_init2_req+0x720/0x720 [bluetooth]
 [<ffffffffa016ea06>] __hci_req_sync+0xd6/0x1c0 [bluetooth]
 [<ffffffff8108ee10>] ? try_to_wake_up+0x2b0/0x2b0
 [<ffffffff8150e3f0>] ? usb_autopm_put_interface+0x30/0x40
 [<ffffffffa016fad5>] hci_dev_open+0x275/0x2e0 [bluetooth]
 [<ffffffffa0182752>] hci_sock_ioctl+0x1f2/0x3f0 [bluetooth]
 [<ffffffff815c6050>] sock_do_ioctl+0x30/0x70
 [<ffffffff815c75f9>] sock_ioctl+0x79/0x2f0
 [<ffffffff811a8046>] do_vfs_ioctl+0x96/0x560
 [<ffffffff811a85a1>] SyS_ioctl+0x91/0xb0
 [<ffffffff816d989d>] system_call_fastpath+0x1a/0x1f
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

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>

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>

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>

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>

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 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 are new sparse warnings show up in

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next master
head:   a0b644b0385fa58ca578f6dce4473e8a8e6f6c38
commit: 75e84b7c Bluetooth: Add __hci_cmd_sync() helper function
date:   13 days ago

>> net/bluetooth/hci_core.c:82:16: sparse: symbol 'hci_get_cmd_complete' was not declared. Should it be static?
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Acked-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The Bluetooth Core Specification (4.0) defines the Write LE Host
Supported HCI command as only available for controllers supporting
BR/EDR. This is further reflected in the Read Local Extended Features
HCI command also not being available for LE-only controllers. In other
words, host-side LE support is implicit for single-mode LE controllers
and doesn't have explicit HCI-level enablement.

This patch ensures that the LE setting is always exposed as enabled
through mgmt and returns a "rejected" response if user space tries to
toggle the setting. The patch also ensures that Write LE Host Supported
is never sent for LE-only controllers.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

All HCI command send functions that take a pointer to the command
parameters do not need to modify the content in any way (they merely
copy the data to an skb). Therefore, the parameter type should be
declared const. This also allows passing already const parameters to
these APIs which previously would have generated a compiler warning.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

This patch renames LE_SCANNING_ENABLED and LE_SCANNING_DISABLED
macros to LE_SCAN_ENABLE and LE_SCAN_DISABLE in order to keep
the same prefix others LE scan macros have.

It also fixes le_scan_enable_req function so it uses the LE_SCAN_
ENABLE macro instead of a magic number.
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 adds macros for filter_duplicates parameter values from
HCI LE Set Scan Enable command. It also fixes le_scan_enable_req
function so it uses the LE_SCAN_FILTER_DUP_ENABLE macro instead of
a magic number.

The LE_SCAN_FILTER_DUP_DISABLE was also defined since it will be
required to properly support the GAP Observer Role.
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>

Define LE scanning timeout macros in jiffies just like we do for
others timeout macros.
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>

With the introduction of CSA4 there is now also a features page number 2
available. This patch increments the maximum supported page number to 2
and adds code for reading all available pages (as long as we have
support for them - indicated by HCI_MAX_PAGES).
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The driver init queue is no longer needed. This can be all handled
inside the drivers now. So remove it.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Some drivers require a special stage for their early init. This is
always specific to the driver or transport. So call back into driver to
allow bringing up the device.

The advantage with this stage is that the Bluetooth core is actually
handling the HCI layer now. This means that command and event processing
is available.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

This patch adds a __hci_cmd_sync_ev function, analogous to
__hci_cmd_sync except that it also takes an event parameter to indicate
that the command completes with a special event instead of command
complete. Internally this new function takes advantage of the
hci_req_add_ev function introduced in the previous patch.

The primary expected user of this new function are the setup routines of
HCI drivers which may want to send custom commands and return only when
they have completed.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds support for having commands within HCI requests that do
not result in a command complete but some other event. This is at least
needed for some vendor specific commands to be issued in the
hdev->setup() procecure, but might also be useful for other commands.

The way that the support is implemented is by extending the skb control
buffer to have a field to indicate that the command is expected to
terminate with a special event. After sending the command each received
event can then be compared against this field through hdev->sent_cmd.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds a helper function for sending a single HCI command
waiting for its completion and then returning back the parameters in the
resulting command complete event (if there was one).

The implementation is very similar to that of hci_req_sync() except that
instead of invocing a callback for sending HCI commands the function
constructs and sends one itself and after being woken up picks the last
received event from hdev->recv_evt (if it matches the right criteria)
and returns it.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds tracking of received HCI events to the hci_dev struct.
This is necessary so that a subsequent patch can implement a function
for sending a single command synchronously and returning the resulting
command complete parameters in the function return value.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>

This patch removes the hci_req_cmd_status function since it is not
used anymore. The HCI request framework now considers the HCI command
has complete once the Command Status or Command Complete Event is
received.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Since the HCI request framework was properly fixed, the hci_req_sync
call, in hci_inquiry, will return as soon as the HCI command completes
(not the Inquiry procedure). However, in inquiry ioctl implementation,
we want to sleep the user process until the inquiry procedure finishes.

This patch changes hci_inquiry so, in case the HCI Inquiry command
was executed successfully, it waits the HCI_INQUIRY flag to be cleared.
This way, the user process will sleep until the inquiry procedure
finishes.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

These parameters are related to the "fast connectable" mode that can be
changed through the mgmt interface. Not all controllers properly reset
these values with HCI_Reset so they need to be read in order to be able
to verify whether the values are correct or not before enabling page
scan.
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>

For proper control of the AD update and the related HCI commands it's
best to run the AD update through an async request instead of a
standalone HCI command. This patch changes the hci_update_ad() function
to take a request pointer and updates its users appropriately. E.g. the
function is no longer called after the init sequence but during stage 3
of the init sequence.

The TX power is read during the init sequence, so we don't need an
explicit update whenever it is read and the AD update based on the local
name should be done through the local name mgmt handler. The only other
user is the update based on enabling advertising. This part is still
kept as there is no mgmt API to enable it.
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>

When powering off the device the hdev->flags and hdev->dev_flags need to
be cleared before calling mgmt_powered(). If this is not done the
resulting events sent to user space may contain incorrect values.

Note that the HCI_AUTO_OFF flag accessed right after this is part of the
persistent flags, so it's unchanged by the hdev->dev_flags reset.
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>

When hci_dev_do_close() is called we should make sure to clear all
non-persistent flags in hci->dev_flags.
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>

If req->err is set, there is no point in queueing the HCI command
in HCI request command queue since it won't be sent anyway.
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>

Since no one checks the returning value of hci_req_add and HCI
request errors are now handled in hci_req_run, we can make hci_
req_add returning void.
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>

When we are building a HCI request with more than one HCI command
and one of the hci_req_add calls fail, we should have some cleanup
routine so the HCI commands already queued on HCI request can be
deleted. Otherwise, we will face some memory leaks issues.

This patch implements the HCI request error handling which is the
following: If a hci_req_add fails, we save the error code in hci_
request. Once hci_req_run is called, we verify the error field. If
it is different from zero, we delete all HCI commands already queued
and return the error code.
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>

Since hci_req_run will be returning more than one error code, we
should check its returning value in __hci_req_sync.
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 case the HCI request queue is empty, hci_req_run should return
ENODATA instead of EINVAL. This way, hci_req_run returns a more
meaningful error value.
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>

If hci_req_run returns error, we erroneously leave the current
process in TASK_INTERRUPTABLE state. If we leave the process in
TASK_INTERRUPTABLE and it is preempted, this process will never
be scheduled again.

This patch fixes this issue by moving the preparation for scheduling
(add to waitqueue and set process state) to just after the hci_req_run
call.
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 variable is no longer needed (due to async HCI request support and
the conversion of hci_req_sync to use it), so it can be safely removed.
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>

This patch converts the hci_req_sync() procedure to internaly use the
asynchronous HCI requests.

The hci_req_sync mechanism relies on hci_req_complete() calls from
hci_event.c into hci_core.c whenever a HCI command completes. This is
very similar to what asynchronous requests do and makes the conversion
fairly straight forward by converting hci_req_complete into a request
complete callback. By this change hci_req_complete (renamed to
hci_req_sync_complete) becomes private to hci_core.c and all calls to it
can be removed from hci_event.c.

The commands in each hci_req_sync procedure are collected into their own
request by passing the hci_request pointer to the request callback
(instead of the hci_dev pointer). The one slight exception is the HCI
init request which has the special handling of HCI driver specific
initialization commands. These commands are run in their own request
prior to the "main" init request.

One other extra change that this patch must contain is the handling of
spontaneous HCI reset complete events that some controllers exhibit.
These were previously handled in the hci_req_complete function but the
right place for them now becomes the hci_req_cmd_complete function.
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>