In some circumstances we need to look up entries in pend_le_conns and in
other in pend_le_reports. This patch converts the existing lookup
function for pend_le_conns to something that can be used for both lists.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Since there are no more users of this function we can simply go ahead
and remove it.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This is the last place using hci_pend_le_conn_add() and we can more
just as simply manipulate the list directly here.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When powering off (hci_dev_do_close) we should clear both the
pend_le_reports and pend_le_conns types of entries. When powering on
respectively we should populate both lists. This patch converts the
hci_pend_le_conns_clear() function into hci_pend_le_actions_clear()
(which can now be static) and converts the restart_le_auto_conns()
function into restart_le_actions().
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Now that there are no-longer any users of the hci_pend_le_conn_del()
function we can simply go ahead and remove it.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Since params->action is used for both the pend_le_conns and
pend_le_reports lists we can simplify the adding and deleting of the
lists considerably. For example, when deleting entries in most
situations we no-longer need to check the auto_connect value but can
directly proceed with calling list_del_init on param->action (which is
safe even if the entry is not part of any list).
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When hci_conn_params_set() is called if the new auto_connect value is
the same as the old one we don't need to take any action. Simply return
success from the function in this case.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Now that pend_le_connections is a list of hci_conn_params entries we can
simply remove items from that list as we iterate through the global list
of le_conn_params. This also moves the responsibility of calling
hci_update_background_scan() to the functions that were previously
calling hci_pend_le_conns_clear(). The only user that's left for
hci_pend_le_conns_clear() is hci_dev_do_close() which anyway does not
need to call hci_update_background_scan().
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To simplify manipulation and lookup of hci_conn_params entries of the
type HCI_AUTO_CONN_REPORT it makes sense to store them in their own
list. The new action list_head in hci_conn_params is used for this
purpose.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In preparation to store also HCI_AUTO_CONN_REPORT entries in a list it
makes sense to convert the existing pend_le_conn list head of
hci_conn_params into a more generically named "action". This makes sense
because a parameter entry will never participate in more than one action
list.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If we're doing passive scanning we shouldn't proceed with any of the
code that deals with active scanning (pending reports, etc.). This patch
fixes a missing return statement for the passive scanning section in the
process_adv_report() function.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Read Controller Configuration Information command allows retrieving
details about possible configurations option. The supported options are
returned and also the missing options (if any).
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Since we only store entries with identity addresses in the
le_conn_params and pend_le_conns lists we can avoid unnecessary lookups
by checking for an identity address before diving into the lists
themselves.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If a device is in the pend_le_conns list it cannot at the same time also
have the need to be notified through mgmt_device_found. By making
check_pending_le_conn return whether it found an entry or not we can
avoid unnecessary checks in process_adv_report().
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Since the connection parameters are always a basis for adding entries to
hdev->pend_le_conns (so far of type bdaddr_list) it's simpler and more
efficient to have the parameters themselves be the entries in the
pend_le_conns list. We do this by adding another list_head to the
hci_conn_params struct.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When processing passive scanning results we need the resolved identity
address both in check_pending_le_conn() as well as later in
process_adv_report(). Since process_adv_report() calls
check_pending_le_conn() we can simply resolve the IRK earlier in the
function and thereby eliminate a second lookup.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When calling Remove Device for an entry using HCI_AUTO_CONN_REPORT we
need to decrement the pend_le_reports value correspondingly. This patch
fixes one such missing action in the Remove Device command handler.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The handler for variable length commands were trying to calculate the
expected length of the command based on the given parameter count, and
then comparing that with the received data. However, the expected count
was stored in a u16 which can easily overflow. With a carefully crafted
command this can then be made to match the given data even though the
parameter count is actually way too big, resulting in a buffer overflow
when parsing the parameters.

This patch fixes the issue by calculating a per-command maximum
parameter count and returns INVALID_PARAMS if it is exceeded.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When we're scanning for specific devices that use an RPA we need to
convert the RPA to the identity address before looking up the entry in
the connection parameters. This patch adds the necessary code to do this
in the process_adv_report() function.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If we have one or more devices with HCI_AUTO_CONN_REPORT we should do
background scanning and emit mgmt_device_found events. This patch
modifies the hci_update_background_scan() function to extend the
conditions needed to trigger scanning, and adds the necessary code to
process_adv_report() to emit mgmt_device_found events.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When the kernel is doing LE scanning because of one or more devices
added with action 0x00 through the Add Device command we do want to let
mgmt_device_found() to proceed with sending an event. This kind of
devices are tracked with hdev->pend_le_reports, so check this value
before bailing out from the function.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To be able to make the right choice of whether to start passive scanning
or to send out a mgmt_device_found event we need to know if there are
any devices in the le_conn_params list with the auto_connect value set
to HCI_AUTO_CONN_REPORT. This patch adds a counter for this kind of
devices.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This adds support for configuring the hci_vhci virtual controllers
as a raw-only device using HCI_QUIRK_RAW_DEVICE. This is useful for
testing the kernel internal infrastructure.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

This command allows to get the list of currently known controller that
are in unconfigured state.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When a controller in an unconfigured state gets removed, then send
Unconfigured Index Removed events.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When a controller is in unconfigured state it is currently hidden
from the management interface. This change now announces the new
controller with an Unconfigured Index Added event and allows clients
to easily detect the controller.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

With the new unconfigured controller state it is possible to provide a
fully functional HCI transport, but disable the higher level operations
that would normally happen. This way userspace can try to configure the
controller before releases the unconfigured state.

The internal state is represented by HCI_UNCONFIGURED. This replaces the
HCI_QUIRK_RAW_DEVICE quirk as internal state representation. This is now
a real state and drivers can use the quirk to actually trigger this
state. In the future this will allow a more fine grained switching from
unconfigured state to configured state for controller inititialization.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

If we don't have an identity address for connection parameters it
doesn't really make sense to send them to user space. Instead just
ignore them for now. Later we can add support for sending them when we
eventually get the identity through pairing.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

There are more places that can take advantage of is_identity_address()
besides hci_core.c. This patch moves the function to hci_core.h and
gives it the appropriate hci_ prefix.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The calling functions of mgmt_new_conn_param have more information about
the parameters, such as whether the kernel is tracking them or not. It
makes therefore sense to have them pass an initial store_hint value to
the mgmt_new_conn_param function.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The caller of hci_le_conn_update is directly interested in knowing what
the best value is for the store_hint parameter of the corresponding
mgmt event. Since hci_le_conn_update knows whether there were stored
parameters that were updated or not we can have it return an initial
store_hint value to the caller.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

We should update any stored connection parameters when we receive the LE
Remote Connection Parameter Request HCI event. This patch adds the
necessary code to the function that handles the event.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch implements the new Load Connection Parameters mgmt command
that's intended to load the desired connection parameters for LE
devices.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Remove Device mgmt command is supposed to undo what the Add Device
command does. An entry added by Add Device cannot have the
HCI_AUTO_CONN_DISABLED auto_connect value, so we should treat this as an
invalid entry to remove. This patch adds the necessary pieces to the
Remove Device command handler so that it only removes entries which were
added by Add Device.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The 0x00 action value of mgmt means "scan and report" but do not
connect. This is different from HCI_AUTO_CONN_DISABLED so we need a new
value for it.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In some circumstances we'll need to either clear only the enabled
parameters or only the disabled ones. This patch adds convenience
functions for this purpose.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

We'll soon have specific clear functions for clearing enabled or
disabled entries, so rename the function that removes everything to
clear_all().
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch fixes the following sparse warning caused by a missing
declaration in the header file:

drivers/bluetooth/btmrvl_main.c:218:5: warning: symbol 'btmrvl_pscan_window_reporting' was not declared. Should it be static?
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Broadcom BCM20702A0 USB controllers might come with the default
address 00:20:70:02:A0:00 when booting up. If this happens, then warn
about such address being used.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Some Intel Bluetooth controllers come with a default address. If this
address is found, print an error to warn the user about it.

The controller is fully operational, but the danger of duplicate
Bluetooth addresses might causes issues. At least with a clear
error it becomes easier to debug these cases.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>