summaryrefslogtreecommitdiffstats
path: root/net/bluetooth/hci_request.c
AgeCommit message (Collapse)AuthorFilesLines
2021-04-06Bluetooth: LL privacy allow RPASathish Narasimman1-0/+4
allow RPA to add bd address to whitelist Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-04-06Bluetooth: Handle own address type change with HCI_ENABLE_LL_PRIVACYSathish Narasimman1-2/+4
own_address_type has to changed to 0x02 and 0x03 only when HCI_ENABLE_LL_PRIVACY flag is set. Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-04-02Bluetooth: Check inquiry status before sending oneArchie Pusaka1-0/+3
There is a possibility where HCI_INQUIRY flag is set but we still send HCI_OP_INQUIRY anyway. Such a case can be reproduced by connecting to an LE device while active scanning. When the device is discovered, we initiate a connection, stop LE Scan, and send Discovery MGMT with status disabled, but we don't cancel the inquiry. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-04-02Bluetooth: Coding style fixMeng Yu1-4/+2
1. Add space when needed; 2. Block comments style fix; 3. Move open brace '{' following function definitions to the next line; 4. Remove unnecessary braces '{}' for single statement blocks. Signed-off-by: Meng Yu <yumeng18@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-03-15Bluetooth: Cancel le_scan_restart work when stopping discoverySonny Sasaka1-0/+1
Not cancelling it has caused a bug where passive background scanning is disabled out of the blue, preventing BLE keyboards/mice to reconnect. Here is how it happens: After hci_req_stop_discovery, there is still le_scan_restart_work scheduled. Invocation of le_scan_restart_work causes a harmful le_scan_disable_work to be scheduled. This le_scan_disable_work will eventually disable passive scanning when the timer fires. Sample btmon trace: < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 Type: Passive (0x00) Interval: 367.500 msec (0x024c) Window: 37.500 msec (0x003c) Own address type: Public (0x00) Filter policy: Accept all advertisement (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Scan Parameters (0x08|0x000b) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 Scanning: Enabled (0x01) Filter duplicates: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Scan Enable (0x08|0x000c) ncmd 2 Status: Success (0x00) ... < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 Scanning: Disabled (0x00) Filter duplicates: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Scan Enable (0x08|0x000c) ncmd 2 Status: Success (0x00) // Background scanning is not working here onwards. Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-03-03Bluetooth: Allow scannable adv with extended MGMT APIsDaniel Winkler1-1/+2
An issue was found, where if a bluetooth client requests a broadcast advertisement with scan response data, it will not be properly registered with the controller. This is because at the time that the hci_cp_le_set_scan_param structure is created, the scan response will not yet have been received since it comes in a second MGMT call. With empty scan response, the request defaults to a non-scannable PDU type. On some controllers, the subsequent scan response request will fail due to incorrect PDU type, and others will succeed and not use the scan response. This fix allows the advertising parameters MGMT call to include a flag to let the kernel know whether a scan response will be coming, so that the correct PDU type is used in the first place. A bluetoothd change is also incoming to take advantage of it. To test this, I created a broadcast advertisement with scan response data and registered it on the hatch chromebook. Without this change, the request fails, and with it will succeed. Reviewed-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-03-03Bluetooth: Remove unneeded commands for suspendAbhishek Pandit-Subedi1-17/+27
During suspend, there are a few scan enable and set event filter commands that don't need to be sent unless there are actual BR/EDR devices capable of waking the system. Check the HCI_PSCAN bit before writing scan enable and use a new dev flag, HCI_EVENT_FILTER_CONFIGURED to control whether to clear the event filter. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-01-25Bluetooth: disable advertisement filters during suspendHoward Chung1-0/+29
This adds logic to disable and reenable advertisement filters during suspend and resume. After this patch, we would only receive packets from devices in allow list during suspend. Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-01-25Bluetooth: advmon offload MSFT interleave scanning integrationArchie Pusaka1-9/+11
When MSFT extension is supported, we don't have to interleave the scan as we could just do allowlist scan. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-12-18Bluetooth: Remove hci_req_le_suspend_configAbhishek Pandit-Subedi1-17/+8
Add a missing SUSPEND_SCAN_ENABLE in passive scan, remove the separate function for configuring le scan during suspend and update the request complete function to clear both enable and disable tasks. Fixes: dce0a4be8054 ("Bluetooth: Set missing suspend task bits") Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-12-07Bluetooth: Set missing suspend task bitsAbhishek Pandit-Subedi1-0/+8
When suspending, mark SUSPEND_SCAN_ENABLE and SUSPEND_SCAN_DISABLE tasks correctly when either classic or le scanning is modified. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Use intervals and tx power from mgmt cmdsDaniel Winkler1-10/+19
This patch takes the min/max intervals and tx power optionally provided in mgmt interface, stores them in the advertisement struct, and uses them when configuring the hci requests. While tx power is not used if extended advertising is unavailable, software rotation will use the min and max advertising intervals specified by the client. This change is validated manually by ensuring the min/max intervals are propagated to the controller on both hatch (extended advertising) and kukui (no extended advertising) chromebooks, and that tx power is propagated correctly on hatch. These tests are performed with multiple advertisements simultaneously. Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Add toggle to switch off interleave scanHoward Chung1-1/+2
This patch add a configurable parameter to switch off the interleave scan feature. Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Handle active scan caseHoward Chung1-1/+3
This patch adds code to handle the active scan during interleave scan. The interleave scan will be canceled when users start active scan, and it will be restarted after active scan stopped. Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Manish Mandlik <mmandlik@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Handle system suspend resume caseHoward Chung1-1/+3
This patch adds code to handle the system suspension during interleave scan. The interleave scan will be canceled when the system is going to sleep, and will be restarted after waking up. Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Manish Mandlik <mmandlik@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Interleave with allowlist scanHoward Chung1-7/+121
This patch implements the interleaving between allowlist scan and no-filter scan. It'll be used to save power when at least one monitor is registered and at least one pending connection or one device to be scanned for. The durations of the allowlist scan and the no-filter scan are controlled by MGMT command: Set Default System Configuration. The default values are set randomly for now. Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Manish Mandlik <mmandlik@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Rename get_adv_instance_scan_rspLuiz Augusto von Dentz1-23/+9
This renames get_adv_instance_scan_rsp to adv_instance_is_scannable and make it return a bool since it was not actually properly return the size of the scan response as one could expect. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-12-07Bluetooth: Fix not sending Set Extended Scan ResponseLuiz Augusto von Dentz1-8/+6
Current code is actually failing on the following tests of mgmt-tester because get_adv_instance_scan_rsp_len did not account for flags that cause scan response data to be included resulting in non-scannable instance when in fact it should be scannable. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-11-11Bluetooth: Replace BT_DBG with bt_dev_dbg in HCI requestHoward Chung1-26/+26
This replaces the BT_DBG function to bt_dev_dbg as it is cleaner to show the controller index in the debug message. Signed-off-by: Howard Chung <howardchung@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-11-09Bluetooth: Fix: LL PRivacy BLE device fails to connectSathish Narasimman1-4/+8
When adding device to white list the device is added to resolving list also. It has to be added only when HCI_ENABLE_LL_PRIVACY flag is set. HCI_ENABLE_LL_PRIVACY flag has to be tested before adding/deleting devices to resolving list. use_ll_privacy macro is used only to check if controller supports LL_Privacy. https://bugzilla.kernel.org/show_bug.cgi?id=209745 Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-11-09Bluetooth: Resume advertising after LE connectionDaniel Winkler1-5/+16
When an LE connection request is made, advertising is disabled and never resumed. When a client has an active advertisement, this is disruptive. This change adds resume logic for client-configured (non-directed) advertisements after the connection attempt. The patch was tested by registering an advertisement, initiating an LE connection from a remote peer, and verifying that the advertisement is re-activated after the connection is established. This is performed on Hatch and Kukui Chromebooks. Signed-off-by: Daniel Winkler <danielwinkler@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-25Bluetooth: Fix update of own_addr_type if ll_privacy supportedSathish Narasimman1-1/+7
During system powercycle when trying to get the random address hci_get_random_address set own_addr_type as 0x01. In which if we enable ll_privacy it is supposed to be 0x03. Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-20Bluetooth: Set scan parameters for ADV MonitorHoward Chung1-0/+3
Set scan parameters when there is at least one Advertisement monitor. Signed-off-by: Howard Chung <howardchung@google.com> Reviewed-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Manish Mandlik <mmandlik@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-14Bluetooth: pause/resume advertising around suspendDaniel Winkler1-10/+57
Currently, the controller will continue advertising when the system enters suspend. This patch makes sure that all advertising instances are paused when entering suspend, and resumed when suspend exits. The Advertising and Suspend/Resume test suites were both run on this change on 4.19 kernel with both hardware offloaded multi-advertising and software rotated multi-advertising. In addition, a new test was added that performs the following steps: * Register 3 advertisements via bluez RegisterAdvertisement * Verify reception of all advertisements by remote peer * Enter suspend on DUT * Verify failure to receive all advertisements by remote peer * Exit suspend on DUT * Verify reception of all advertisements by remote peer Signed-off-by: Daniel Winkler <danielwinkler@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-09-13Bluetooth: Set ext scan response only when it existsAbhishek Pandit-Subedi1-2/+5
Only set extended scan response only when it exists. Otherwise, clear the scan response data. Per the core spec v5.2, Vol 4, Part E, 7.8.55 If the advertising set is non-scannable and the Host uses this command other than to discard existing data, the Controller shall return the error code Invalid HCI Command Parameters (0x12). On WCN3991, the controller correctly responds with Invalid Parameters when this is sent. That error causes __hci_req_hci_power_on to fail with -EINVAL and LE devices can't connect because background scanning isn't configured. Here is an hci trace of where this issue occurs during power on: < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 Handle: 0x00 Properties: 0x0010 Use legacy advertising PDUs: ADV_NONCONN_IND Min advertising interval: 181.250 msec (0x0122) Max advertising interval: 181.250 msec (0x0122) Channel map: 37, 38, 39 (0x07) Own address type: Random (0x01) Peer address type: Public (0x00) Peer address: 00:00:00:00:00:00 (OUI 00-00-00) Filter policy: Allow Scan Request from Any, Allow Connect... TX power: 127 dbm (0x7f) Primary PHY: LE 1M (0x01) Secondary max skip: 0x00 Secondary PHY: LE 1M (0x01) SID: 0x00 Scan request notifications: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 5 LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1 Status: Success (0x00) TX power (selected): 9 dbm (0x09) < HCI Command: LE Set Advertising Set Random Address (0x08|0x0035) plen 7 Advertising handle: 0x00 Advertising random address: 08:FD:55:ED:22:28 (OUI 08-FD-55) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertising Set Random Address (0x08|0x0035) ncmd Status: Success (0x00) < HCI Command: LE Set Extended Scan Response Data (0x08|0x0038) plen 35 Handle: 0x00 Operation: Complete scan response data (0x03) Fragment preference: Minimize fragmentation (0x01) Data length: 0x0d Name (short): Chromebook > HCI Event: Command Complete (0x0e) plen 4 LE Set Extended Scan Response Data (0x08|0x0038) ncmd 1 Status: Invalid HCI Command Parameters (0x12) Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-31Bluetooth: use the proper scan params when conn is pendingAlain Michaud1-0/+24
When an LE connection is requested and an RPA update is needed via hci_connect_le_scan, the default scanning parameters are used rather than the connect parameters. This leads to significant delays in the connection establishment process when using lower duty cycle scanning parameters. The patch simply looks at the pended connection list when trying to determine which scanning parameters should be used. Before: < HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8                             #378 [hci0] 1659.247156         Own address type: Public (0x00)         Filter policy: Ignore not in white list (0x01)         PHYs: 0x01         Entry 0: LE 1M           Type: Passive (0x00)           Interval: 367.500 msec (0x024c)           Window: 37.500 msec (0x003c) After: < HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8                               #39 [hci0] 7.422109         Own address type: Public (0x00)         Filter policy: Ignore not in white list (0x01)         PHYs: 0x01         Entry 0: LE 1M           Type: Passive (0x00)           Interval: 60.000 msec (0x0060)           Window: 60.000 msec (0x0060) Signed-off-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Yu Liu <yudiliu@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-30Bluetooth: Enable controller RPA resolution using Experimental featureSathish Narasimman1-1/+6
This patch adds support to enable the use of RPA Address resolution using expermental feature mgmt command. Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-30Bluetooth: Enable/Disable address resolution during le create connSathish Narasimman1-11/+34
In this patch if le_create_conn process is started restrict to disable address resolution and same is disabled during le_enh_connection_complete Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-30Bluetooth: Let controller creates RPA during le create connSathish Narasimman1-1/+7
When address resolution is enabled and set_privacy is enabled let's use own address type as 0x03 Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-30Bluetooth: Update resolving list when updating whitelistMarcel Holtmann1-2/+39
When the whitelist is updated, then also update the entries of the resolving list for devices where IRKs are available. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-30Bluetooth: Configure controller address resolution if availableMarcel Holtmann1-3/+23
When the LL Privacy support is available, then as part of enabling or disabling passive background scanning, it is required to set up the controller based address resolution as well. Since only passive background scanning is utilizing the whitelist, the address resolution is now bound to the whitelist and passive background scanning. All other resolution can be easily done by the host stack. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-15Bluetooth: Add per-instance adv disable/removeDaniel Winkler1-9/+50
Add functionality to disable and remove advertising instances, and use that functionality in MGMT add/remove advertising calls. Currently, advertising is globally-disabled, i.e. all instances are disabled together, even if hardware offloading is available. This patch adds functionality to disable and remove individual adv instances, solving two issues: 1. On new advertisement registration, a global disable was done, and then only the new instance was enabled. This meant only the newest instance was actually enabled. 2. On advertisement removal, the structure was removed, but the instance was never disabled or removed, which is incorrect with hardware offload support. Signed-off-by: Daniel Winkler <danielwinkler@google.com> Reviewed-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-08Bluetooth: Use whitelist for scan policy when suspendingMiao-chen Chou1-2/+3
Even with one advertisement monitor in place, the scan policy should use the whitelist while the system is going to suspend to prevent waking by random advertisement. The following test was performed. - With a paired device, register one advertisement monitor, suspend the system and verify that the host was not awaken by random advertisements. Signed-off-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-07-07Bluetooth: use configured default params for active scansAlain Michaud1-5/+6
This patch fixes active scans to use the configured default parameters. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-24Bluetooth: Don't restart scanning if pausedAbhishek Pandit-Subedi1-0/+10
When restarting LE scanning, check if it's currently paused before enabling passive scanning. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-22Bluetooth: use configured params for ext advAlain Michaud1-4/+3
When the extended advertisement feature is enabled, a hardcoded min and max interval of 0x8000 is used. This patch fixes this issue by using the configured min/max value. This was validated by setting min/max in main.conf and making sure the right setting is applied: < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 #93 [hci0] 10.953011 … Min advertising interval: 181.250 msec (0x0122) Max advertising interval: 181.250 msec (0x0122) … Signed-off-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-18Bluetooth: Update background scan and report device based on advertisement ↵Miao-chen Chou1-3/+14
monitors This calls hci_update_background_scan() when there is any update on the advertisement monitors. If there is at least one advertisement monitor, the filtering policy of scan parameters should be 0x00. This also reports device found mgmt events if there is at least one monitor. The following cases were tested with btmgmt advmon-* commands. (1) add a ADV monitor and observe that the passive scanning is triggered. (2) remove the last ADV monitor and observe that the passive scanning is terminated. (3) with a LE peripheral paired, repeat (1) and observe the passive scanning continues. (4) with a LE peripheral paired, repeat (2) and observe the passive scanning continues. (5) with a ADV monitor, suspend/resume the host and observe the passive scanning continues. Signed-off-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Replace wakeable in hci_conn_paramsAbhishek Pandit-Subedi1-1/+2
Replace the wakeable boolean with flags in hci_conn_params and all users of this boolean. This will be used by the get/set device flags mgmt op. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-18Bluetooth: Replace wakeable list with flagAbhishek Pandit-Subedi1-4/+8
Since the classic device list now supports flags, convert the wakeable list into a flag on the existing device list. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-06-12Bluetooth: centralize default value initialization.Alain Michaud1-10/+5
This patch centralized the initialization of default parameters. This is required to allow clients to more easily customize the default system parameters. Signed-off-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-06-03Bluetooth: Check scan state before disabling during suspendManish Mandlik1-4/+6
Check current scan state by checking HCI_LE_SCAN flag and send scan disable command only if scan is already enabled. Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-05-13Bluetooth: Rename BT_SUSPEND_COMPLETEAbhishek Pandit-Subedi1-1/+1
Renamed BT_SUSPEND_COMPLETE to BT_SUSPEND_CONFIGURE_WAKE since it sets up the event filter and whitelist for wake-up. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-05-13Bluetooth: Modify LE window and interval for suspendAbhishek Pandit-Subedi1-1/+1
When a device is suspended, it doesn't need to be as responsive to connection events. Increase the interval to 640ms (creating a duty cycle of roughly 1.75%) so that passive scanning uses much less power (vs previous duty cycle of 18.75%). The new window + interval combination has been tested to work with HID devices (which are currently the only devices capable of wake up). Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-05-13Bluetooth: Fix incorrect type for window and intervalAbhishek Pandit-Subedi1-1/+1
The types for window and interval should be uint16, not uint8. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-05-11Bluetooth: Fix advertising handle is set to 0Tedd Ho-Jeong An1-3/+3
This patch fix the advertising handle is set to 0 regardless of actual instance value. The affected commands are LE Set Advertising Set Random Address, LE Set Extended Advertising Data, and LE Set Extended Scan Response Data commands. Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-04-15Bluetooth: Use extra variable to make code more readableMarcel Holtmann1-1/+3
When starting active scanning for discovery the whitelist is not needed to be used. So the filter_policy is 0x00. To make the core more readable use a variable name instead of just setting 0 as paramter. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2020-03-18Bluetooth: Do not cancel advertising when starting a scanDmitry Grinberg1-17/+0
BlueZ cancels adv when starting a scan, but does not cancel a scan when starting to adv. Neither is required, so this brings both to a consistent state (of not affecting each other). Some very rare (I've never seen one) BT 4.0 chips will fail to do both at once. Even this is ok since the command that will fail will be the second one, and thus the common sense logic of first-come-first-served is preserved for BLE requests. Signed-off-by: Dmitry Grinberg <dmitrygr@google.com> Signed-off-by: Manish Mandlik <mmandlik@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-03-11Bluetooth: Pause discovery and advertising during suspendAbhishek Pandit-Subedi1-0/+44
To prevent spurious wake ups, we disable any discovery or advertising when we enter suspend and restore it when we exit suspend. While paused, we disable any management requests to modify discovery or advertising. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-03-11Bluetooth: Handle LE devices during suspendAbhishek Pandit-Subedi1-54/+112
To handle LE devices, we must first disable passive scanning and disconnect all connected devices. Once that is complete, we update the whitelist and re-enable scanning Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-03-11Bluetooth: Handle BR/EDR devices during suspendAbhishek Pandit-Subedi1-0/+106
To handle BR/EDR devices, we first disable page scan and disconnect all connected devices. Once that is complete, we add event filters (for devices that can wake the system) and re-enable page scan. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>