- 04 Jul, 2014 8 commits
-
-
Johan Hedberg authored
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:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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: -
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Marcel Holtmann authored
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:
-
- 03 Jul, 2014 32 commits
-
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
This command allows to get the list of currently known controller that are in unconfigured state. Signed-off-by:
-
Marcel Holtmann authored
When a controller in an unconfigured state gets removed, then send Unconfigured Index Removed events. Signed-off-by:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Johan Hedberg authored
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:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
When allocating a new controller structure, then default to the internal use value 0xffff first. Default to 0x0000 is a bad idea since that is the manufacturer identifier of Ericsson Technology Licensing. Signed-off-by:
-
Marcel Holtmann authored
For the Intel based USB devices add support for configuration of the public device address. Signed-off-by:
-
Johan Hedberg authored
Unlike BR/EDR we cannot reject LE connections of blocked devices but have to do it as soon as we get a LE Connection Complete event. The patch adds a blacklist check to the hci_le_conn_complete_evt function and drops all connections for blocked devices. Signed-off-by:
-
Johan Hedberg authored
The ATT channel isn't the only one that we should ensure doesn't receive data from blocked devices. SMP is another, and in general we don't want data packets going to any of the various handlers. Therefore, add a single check to the l2cap_recv_frame function. The patch fixes at the same time the use of a correct address type. The blacklist stores the values with the user space facing triple type wheras hci_conn->dst_type uses the HCI address type (0x00 or 0x01). Signed-off-by:
-
