linux/include/net/bluetooth, branch v5.12

Bluetooth: Skip eSCO 2M params when not supported

2021-02-01T16:04:17Z

If a peer device doesn't support eSCO 2M we should skip the params that use it when setting up sync connection since they will always fail. Signed-off-by: Yu Liu Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann

Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk

2021-01-29T15:37:00Z

Some devices, e.g. the RTL8723BS bluetooth part, some USB attached devices, completely drop from the bus on a system-suspend. These devices will have their driver unbound and rebound on resume (when the dropping of the bus gets detected) and will show up as a new HCI after resume. These devices do not benefit from the suspend / resume handling work done by the hci_suspend_notifier. At best this unnecessarily adds some time to the suspend/resume time. But this may also actually cause problems, if the code doing the driver unbinding runs after the pm-notifier then the hci_suspend_notifier code will try to talk to a device which is now in an uninitialized state. This commit adds a new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk which allows drivers to opt-out of the hci_suspend_notifier when they know beforehand that their device will be fully re-initialized / reprobed on resume. Signed-off-by: Hans de Goede Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann

Bluetooth: L2CAP: Fix handling fragmented length

2021-01-25T18:26:33Z

Bluetooth Core Specification v5.2, Vol. 3, Part A, section 1.4, table 1.1: 'Start Fragments always either begin with the first octet of the Basic L2CAP header of a PDU or they have a length of zero (see [Vol 2] Part B, Section 6.6.2).' Apparently this was changed by the following errata: https://www.bluetooth.org/tse/errata_view.cfm?errata_id=10216 Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: disable advertisement filters during suspend

2021-01-25T15:07:37Z

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 Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann

Bluetooth: advmon offload MSFT remove monitor

2021-01-25T15:07:36Z

Implements the monitor removal functionality for advertising monitor offloading to MSFT controllers. Supply handle = 0 to remove all monitors. Signed-off-by: Archie Pusaka Reviewed-by: Miao-chen Chou Reviewed-by: Yun-Hao Chung Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Marcel Holtmann

Bluetooth: advmon offload MSFT add monitor

2021-01-25T15:07:36Z

Enables advertising monitor offloading to the controller, if MSFT extension is supported. The kernel won't adjust the monitor parameters to match what the controller supports - that is the user space's responsibility. This patch only manages the addition of monitors. Monitor removal is going to be handled by another patch. Signed-off-by: Archie Pusaka Reviewed-by: Manish Mandlik Reviewed-by: Miao-chen Chou Reviewed-by: Yun-Hao Chung Signed-off-by: Marcel Holtmann

Bluetooth: advmon offload MSFT add rssi support

2021-01-25T15:07:36Z

MSFT needs rssi parameter for monitoring advertisement packet, therefore we should supply them from mgmt. This adds a new opcode to add advertisement monitor with rssi parameters. Signed-off-by: Archie Pusaka Reviewed-by: Manish Mandlik Reviewed-by: Miao-chen Chou Reviewed-by: Yun-Hao Chung Signed-off-by: Marcel Holtmann

Bluetooth: Change MGMT security info CMD to be more generic

2020-12-07T15:01:42Z

For advertising, we wish to know the LE tx power capabilities of the controller in userspace, so this patch edits the Security Info MGMT command to be more generic, such that other various controller capabilities can be included in the EIR data. This change also includes the LE min and max tx power into this newly-named command. The change was tested by manually verifying that the MGMT command returns the tx power range as expected in userspace. Reviewed-by: Sonny Sasaka Signed-off-by: Daniel Winkler Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Query LE tx power on startup

2020-12-07T15:01:38Z

Queries tx power via HCI_LE_Read_Transmit_Power command when the hci device is initialized, and stores resulting min/max LE power in hdev struct. If command isn't available (< BT5 support), min/max values both default to HCI_TX_POWER_INVALID. This patch is manually verified by ensuring BT5 devices correctly query and receive controller tx power range. Reviewed-by: Sonny Sasaka Signed-off-by: Daniel Winkler Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Use intervals and tx power from mgmt cmds

2020-12-07T15:01:33Z

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 Signed-off-by: Daniel Winkler Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg