The hci_dev check is not protected and so move it into the socket lock. In
addition return the HCI channel identifier instead of always 0 channel.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The HCI sockets do not have a peer associated with it and so make sure
that getpeername() returns EOPNOTSUPP since this operation is actually
not supported on HCI sockets.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The handling of the raw socket filter is rather obscure code and it gets
in the way of future extensions. Instead of inline filtering in the raw
socket packet routine, refactor it into its own function.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

When initiating a transparent eSCO connection, make use of T2 settings
at first try. T2 is the recommended settings from HFP 1.6 WideBand
Speech. Upon connection failure, try T1 settings.

When CVSD is requested and eSCO is supported, try to establish eSCO
connection using S3 settings. If it fails, fallback in sequence to S2,
S1, D1, D0 settings.

To know which setting should be used, conn->attempt is used. It
indicates the currently ongoing SCO connection attempt and can be used
as the index for the fallback settings table.

These setting and the fallback order are described in Bluetooth HFP 1.6
specification p. 101.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Synchronous Connection Complete event can return error "Connection
Rejected due to Limited resources (0x10)".
Handling this error is required for SCO connection fallback. This error
happens when the server tried to accept the connection but failed to
negotiate settings.
This error code has been verified experimentally by sending a T2 request
to a T1 only SCO listener.

Client dump follows :

< HCI Command (0x01|0x0028) plen 17 [hci0] 3.696064
        Handle: 12
        Transmit bandwidth: 8000
        Receive bandwidth: 8000
        Max latency: 13
        Setting: 0x0003
        Retransmission effort: Optimize for link quality (0x02)
        Packet type: 0x0380
> HCI Event (0x0f) plen 4 [hci0] 3.697034
      Setup Synchronous Connection (0x01|0x0028) ncmd 1
        Status: Success (0x00)
> HCI Event (0x2c) plen 17 [hci0] 3.736059
        Status: Connection Rejected due to Limited Resources (0x0d)
        Handle: 0
        Address: xx:xx:xx:xx:xx:AB (OUI 70-F3-95)
        Link type: eSCO (0x02)
        Transmission interval: 0x0c
        Retransmission window: 0x06
        RX packet length: 60
        TX packet length: 60
        Air mode: Transparent (0x03)

Server dump follows :

> HCI Event (0x04) plen 10 [hci0] 4.741513
        Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
        Class: 0x620100
          Major class: Computer (desktop, notebook, PDA, organizers)
          Minor class: Uncategorized, code for device not assigned
          Networking (LAN, Ad hoc)
          Audio (Speaker, Microphone, Headset)
          Telephony (Cordless telephony, Modem, Headset)
        Link type: eSCO (0x02)
< HCI Command (0x01|0x0029) plen 21 [hci0] 4.743269
        Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
        Transmit bandwidth: 8000
        Receive bandwidth: 8000
        Max latency: 13
        Setting: 0x0003
        Retransmission effort: Optimize for link quality (0x02)
        Packet type: 0x03c1
> HCI Event (0x0f) plen 4 [hci0] 4.745517
      Accept Synchronous Connection (0x01|0x0029) ncmd 1
        Status: Success (0x00)
> HCI Event (0x2c) plen 17 [hci0] 4.749508
        Status: Connection Rejected due to Limited Resources (0x0d)
        Handle: 0
        Address: xx:xx:xx:xx:xx:D9 (OUI 20-68-9D)
        Link type: eSCO (0x02)
        Transmission interval: 0x0c
        Retransmission window: 0x06
        RX packet length: 60
        TX packet length: 60
        Air mode: Transparent (0x03)
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Older Bluetooth devices may not support Setup Synchronous Connection or
SCO transparent data. This is indicated by the corresponding LMP feature
bits. It is not possible to know if the adapter support these features
before setting BT_VOICE option since the socket is not bound to an
adapter. An adapter can also be added after the socket is created. The
socket can be bound to an address before adapter is plugged in.

Thus, on a such adapters, if user request BT_VOICE_TRANSPARENT, outgoing
connections fail on connect() and returns -EOPNOTSUPP. Incoming
connections do not fail. However, they should only be allowed depending
on what was specified in Write_Voice_Settings command.

EOPNOTSUPP is choosen because connect() system call is failing after
selecting route but before any connection attempt.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
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 order to establish a transparent SCO connection, the correct settings
must be specified in the Setup Synchronous Connection request. For that,
a setting field is added to ACL connection data to set up the desired
parameters. The patch also removes usage of hdev->voice_setting in CVSD
connection and makes use of T2 parameters for transparent data.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
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 an incoming eSCO connection is requested, check the selected voice
setting and reply appropriately. Voice setting should have been
negotiated previously.  For example, in case of HFP, the codec is
negotiated using AT commands on the RFCOMM channel. This patch only
changes replies for socket with deferred setup enabled.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
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 extends the current Bluetooth socket options with BT_VOICE.
This is intended to choose voice data type at runtime. It only applies
to SCO sockets. Incoming connections shall be setup during deferred
setup. Outgoing connections shall be setup before connect(). The desired
setting is stored in the SCO socket info. This patch declares needed
members, modifies getsockopt() and setsockopt().
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

From Bluetooth Core v4.0 specification, 7.1.8 Accept Connection Request
Command "When accepting synchronous connection request, the Role
parameter is not used and will be ignored by the BR/EDR Controller."
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

hci_connect is a super function for connecting hci protocols. But the
voice_setting parameter (introduced in subsequent patches) is only
needed by SCO and security requirements are not needed for SCO channels.
Thus, it makes sense to have a separate function for SCO.
Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In rfcomm_tty_cleanup we purge the dlc->tx_queue which may contain
socket buffers referencing the tty_port and thus preventing the tty_port
destruction.
Signed-off-by: NGianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The tty_port can be released in two cases: when we get a HUP in the
functions rfcomm_tty_hangup() and rfcomm_dev_state_change(). Or when the
user releases the device in rfcomm_release_dev().

In these cases we set the flag RFCOMM_TTY_RELEASED so that no other
function can get a reference to the tty_port.
The use of !test_and_set_bit(RFCOMM_TTY_RELEASED) ensures that the
'initial' tty_port reference is only dropped once.

The rfcomm_dev_del function is removed becase it isn't used anymore.
Signed-off-by: NGianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Implement .activate, .shutdown and .carrier_raised methods of tty_port
to manage the dlc, moving the code from rfcomm_tty_install() and
rfcomm_tty_cleanup() functions.

At the same time the tty .open()/.close() and .hangup() methods are
changed to use the tty_port helpers that properly call the
aforementioned tty_port methods.
Signed-off-by: NGianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Move the tty_struct initialization from rfcomm_tty_open() to
rfcomm_tty_install() and do the same for the cleanup moving the code from
rfcomm_tty_close() to rfcomm_tty_cleanup().

Add also extra error handling in rfcomm_tty_install() because, unlike
.open()/.close(), .cleanup() is not called if .install() fails.
Signed-off-by: NGianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

The current code removes the device from the device list in several
places. Do it only in the destructor instead and in the error path of
rfcomm_add_dev() if the device couldn't be initialized.
Signed-off-by: NGianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

In net/bluetooth/rfcomm/tty.c the struct tty_struct is used without
taking references. This may lead to a use-after-free of the rfcomm tty.

Fix this by taking references properly, using the tty_port_* helpers
when possible.

The raw assignments of dev->port.tty in rfcomm_tty_open/close are
addressed in the later commit 'rfcomm: Implement .activate, .shutdown
and .carrier_raised methods'.
Signed-off-by: NGianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

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>

When a socket is in deferred state there does actually exist an
underlying connection even though the connection state is not yet
BT_CONNECTED. In the deferred state it should therefore be allowed to
get socket options that usually depend on a connection, such as
SCO_OPTIONS and SCO_CONNINFO.

This patch fixes the behavior of some user space code that behaves as
follows without it:

$ sudo tools/btiotest -i 00:1B:DC:xx:xx:xx -d -s
accept=2 reject=-1 discon=-1 defer=1 sec=0 update_sec=0 prio=0 voice=0x0000
Listening for SCO connections
bt_io_get(OPT_DEST): getsockopt(SCO_OPTIONS): Transport endpoint is not connected (107)
Accepting connection
Successfully connected to 60:D8:19:xx:xx:xx. handle=43, class=000000

The conditions that the patch updates the if-statements to is taken from
similar code in l2cap_sock.c which correctly handles the deferred state.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
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>

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>

The USB hid implementation does retrieve the reports during the start.
However, this implementation does not call the HID command GET_REPORT
(which would fetch the current status of each report), but use the
DATA command, which is an Output Report (so transmitting data from the
host to the device).
The Wiimote controller is already guarded against this problem in the
protocol, but it is not conformant to the specification to set all the
reports to 0 on start.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.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>

We can re-enable hidinput_input_event to allow the leds of bluetooth
keyboards to be set.
Now the callbacks uses hid core to retrieve the right HID report to
send, so this version is safer.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.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>

Trivial change in the coding style.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Replace the occurrences of integer literals in hci_event.c with the
newly introduced macros in hci.h.
Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

Make the code in hci_get_auth_req() more readable by using the
defined macros instead of inlining magic numbers.
Signed-off-by: NMikel Astiz <mikel.astiz@bmw-carit.de>
Signed-off-by: NTimo Mueller <timo.mueller@bmw-carit.de>
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>

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>