kernel/linux.git/include/net/bluetooth, branch v5.10.34

Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk

2021-03-07T11:34:10+00:00

[ Upstream commit 219991e6be7f4a31d471611e265b72f75b2d0538 ] 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 Signed-off-by: Sasha Levin

Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel

2020-09-25T18:21:55+00:00

Only sockets will have the chan->data set to an actual sk, channels like A2MP would have its own data which would likely cause a crash when calling sk_filter, in order to fix this a new callback has been introduced so channels can implement their own filtering if necessary. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

Bluetooth: Emit controller suspend and resume events

2020-09-13T07:55:26+00:00

Emit controller suspend and resume events when we are ready for suspend and we've resumed from suspend. The controller suspend event will report whatever suspend state was successfully entered. The controller resume event will check the first HCI event that was received after we finished preparing for suspend and, if it was a connection event, store the address of the peer that caused the event. If it was not a connection event, we mark the wake reason as an unexpected event. Here is a sample btmon trace with these events: @ MGMT Event: Controller Suspended (0x002d) plen 1 Suspend state: Page scanning and/or passive scanning (2) @ MGMT Event: Controller Resumed (0x002e) plen 8 Wake reason: Remote wake due to peer device connection (2) LE Address: CD:F3:CD:13:C5:9A (OUI CD-F3-CD) Signed-off-by: Abhishek Pandit-Subedi Reviewed-by: Miao-chen Chou Signed-off-by: Marcel Holtmann

Bluetooth: Add suspend reason for device disconnect

2020-09-13T07:54:28+00:00

Update device disconnect event with reason 0x5 to indicate that device disconnected because the controller is suspending. Signed-off-by: Abhishek Pandit-Subedi Reviewed-by: Miao-chen Chou Reviewed-by: Sonny Sasaka Signed-off-by: Marcel Holtmann

Bluetooth: Add mgmt suspend and resume events

2020-09-13T07:54:00+00:00

Add the controller suspend and resume events, which will signal when Bluetooth has completed preparing for suspend and when it's ready for resume. Signed-off-by: Abhishek Pandit-Subedi Reviewed-by: Miao-chen Chou Reviewed-by: Sonny Sasaka Signed-off-by: Marcel Holtmann

Bluetooth: Add MGMT capability flags for tx power and ext advertising

2020-09-11T07:17:26+00:00

For new advertising features, it will be important for userspace to know the capabilities of the controller and kernel. If the controller and kernel support extended advertising, we include flags indicating hardware offloading support and support for setting tx power of adv instances. In the future, vendor-specific commands may allow the setting of tx power in advertising instances, but for now this feature is only marked available if extended advertising is supported. This change is manually verified in userspace by ensuring the advertising manager's supported_flags field is updated with new flags on hatch chromebook (ext advertising supported). Signed-off-by: Daniel Winkler Signed-off-by: Marcel Holtmann

Bluetooth: Enable controller RPA resolution using Experimental feature

2020-07-30T09:14:05+00:00

This patch adds support to enable the use of RPA Address resolution using expermental feature mgmt command. Signed-off-by: Sathish Narasimman Signed-off-by: Marcel Holtmann

Bluetooth: Enable RPA Timeout

2020-07-30T07:34:43+00:00

Enable RPA timeout during bluetooth initialization. The RPA timeout value is used from hdev, which initialized from debug_fs Signed-off-by: Sathish Narasimman Signed-off-by: Marcel Holtmann

Bluetooth: Configure controller address resolution if available

2020-07-30T07:34:42+00:00

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 Signed-off-by: Sathish Narsimman Signed-off-by: Marcel Holtmann

Bluetooth: Translate additional address type correctly

2020-07-30T07:34:42+00:00

When using controller based address resolution, then the new address types 0x02 and 0x03 are used. These types need to be converted back into either public address or random address types. Signed-off-by: Marcel Holtmann Signed-off-by: Sathish Narsimman Signed-off-by: Marcel Holtmann