Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
ae753361 |
| 10-May-2023 |
Claudia Draghicescu <claudia.rosu@nxp.com> |
Bluetooth: Check for ISO support in controller
This patch checks for ISO_BROADCASTER and ISO_SYNC_RECEIVER in controller.
Signed-off-by: Claudia Draghicescu <claudia.rosu@nxp.com> Signed-off-by: Lu
Bluetooth: Check for ISO support in controller
This patch checks for ISO_BROADCASTER and ISO_SYNC_RECEIVER in controller.
Signed-off-by: Claudia Draghicescu <claudia.rosu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
show more ...
|
#
73f55453 |
| 07-Jun-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: MGMT: Fix marking SCAN_RSP as not connectable
When receiving a scan response there is no way to know if the remote device is connectable or not, so when it cannot be merged don't make any
Bluetooth: MGMT: Fix marking SCAN_RSP as not connectable
When receiving a scan response there is no way to know if the remote device is connectable or not, so when it cannot be merged don't make any assumption and instead just mark it with a new flag defined as MGMT_DEV_FOUND_SCAN_RSP so userspace can tell it is a standalone SCAN_RSP.
Link: https://lore.kernel.org/linux-bluetooth/CABBYNZ+CYMsDSPTxBn09Js3BcdC-x7vZFfyLJ3ppZGGwJKmUTw@mail.gmail.com/ Fixes: c70a7e4cc8d2 ("Bluetooth: Add support for Not Connectable flag for Device Found events") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12 |
|
#
a80d2c54 |
| 13-Feb-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: MGMT: Use BIT macro when defining bitfields
This makes use of BIT macro when defining bitfields which makes it clearer what bit it is toggling.
Signed-off-by: Luiz Augusto von Dentz <lui
Bluetooth: MGMT: Use BIT macro when defining bitfields
This makes use of BIT macro when defining bitfields which makes it clearer what bit it is toggling.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
show more ...
|
Revision tags: v6.1.11, v6.1.10, v6.1.9 |
|
#
2394186a |
| 30-Jan-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: MGMT: add CIS feature bits to controller information
Userspace needs to know whether the adapter has feature support for Connected Isochronous Stream - Central/Peripheral, so it can set u
Bluetooth: MGMT: add CIS feature bits to controller information
Userspace needs to know whether the adapter has feature support for Connected Isochronous Stream - Central/Peripheral, so it can set up LE Audio features accordingly.
Expose these feature bits as settings in MGMT controller info.
Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65 |
|
#
b338d917 |
| 01-Sep-2022 |
Brian Gix <brian.gix@intel.com> |
Bluetooth: Implement support for Mesh
The patch adds state bits, storage and HCI command chains for sending and receiving Bluetooth Mesh advertising packets, and delivery to requesting user space pr
Bluetooth: Implement support for Mesh
The patch adds state bits, storage and HCI command chains for sending and receiving Bluetooth Mesh advertising packets, and delivery to requesting user space processes. It specifically creates 4 new MGMT commands and 2 new MGMT events:
MGMT_OP_SET_MESH_RECEIVER - Sets passive scan parameters and a list of AD Types which will trigger Mesh Packet Received events
MGMT_OP_MESH_READ_FEATURES - Returns information on how many outbound Mesh packets can be simultaneously queued, and what the currently queued handles are.
MGMT_OP_MESH_SEND - Command to queue a specific outbound Mesh packet, with the number of times it should be sent, and the BD Addr to use. Discrete advertisments are added to the ADV Instance list.
MGMT_OP_MESH_SEND_CANCEL - Command to cancel a prior outbound message request.
MGMT_EV_MESH_DEVICE_FOUND - Event to deliver entire received Mesh Advertisement packet, along with timing information.
MGMT_EV_MESH_PACKET_CMPLT - Event to indicate that an outbound packet is no longer queued for delivery.
Signed-off-by: Brian Gix <brian.gix@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
show more ...
|
Revision tags: v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17 |
|
#
3a031814 |
| 20-Jan-2022 |
Changcheng Deng <deng.changcheng@zte.com.cn> |
Bluetooth: mgmt: Replace zero-length array with flexible-array member
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a struc
Bluetooth: mgmt: Replace zero-length array with flexible-array member
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members" for these cases. The older style of one-element or zero-length arrays should no longer be used. Reference: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays
Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
show more ...
|
#
5224f790 |
| 14-Feb-2022 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure.
treewide: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2].
This code was transformed with the help of Coccinelle: (next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file script.cocci --include-headers --dir . > output.patch)
@@ identifier S, member, array; type T1, T2; @@
struct S { ... T1 member; T2 array[ - 0 ]; };
UAPI and wireless changes were intentionally excluded from this patch and will be sent out separately.
[1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/78 Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
show more ...
|
Revision tags: v5.4.173, v5.15.16, v5.15.15 |
|
#
8d7f1677 |
| 11-Jan-2022 |
Manish Mandlik <mmandlik@google.com> |
Bluetooth: mgmt: Add MGMT Adv Monitor Device Found/Lost events
This patch introduces two new MGMT events for notifying the bluetoothd whenever the controller starts/stops monitoring a device.
Test
Bluetooth: mgmt: Add MGMT Adv Monitor Device Found/Lost events
This patch introduces two new MGMT events for notifying the bluetoothd whenever the controller starts/stops monitoring a device.
Test performed: - Verified by logs that the MSFT Monitor Device is received from the controller and the bluetoothd is notified whenever the controller starts/stops monitoring a device.
Signed-off-by: Manish Mandlik <mmandlik@google.com> Reviewed-by: Miao-chen Chou <mcchou@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
show more ...
|
Revision tags: v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5 |
|
#
ea13aed5 |
| 25-Nov-2021 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: Send device found event on name resolve failure
Introducing NAME_REQUEST_FAILED flag that will be sent together with device found event on name resolve failure. This will provide the user
Bluetooth: Send device found event on name resolve failure
Introducing NAME_REQUEST_FAILED flag that will be sent together with device found event on name resolve failure. This will provide the userspace with an information so it can decide not to resolve the name for these devices in the future.
Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
Revision tags: v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42 |
|
#
fad646e1 |
| 31-May-2021 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: use inclusive language in SMP
This patch replaces some non-inclusive terms based on the appropriate language mapping table compiled by the Bluetooth SIG: https://specificationrefs.bluetoo
Bluetooth: use inclusive language in SMP
This patch replaces some non-inclusive terms based on the appropriate language mapping table compiled by the Bluetooth SIG: https://specificationrefs.bluetooth.com/language-mapping/Appropriate_Language_Mapping_Table.pdf
Specifically, these terms are replaced: master -> initiator slave -> responder
Signed-off-by: Archie Pusaka <apusaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
Revision tags: v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
1c6ed31b |
| 09-Apr-2021 |
Yu Liu <yudiliu@google.com> |
Bluetooth: Return whether a connection is outbound
When an MGMT_EV_DEVICE_CONNECTED event is reported back to the user space we will set the flags to tell if the established connection is outbound o
Bluetooth: Return whether a connection is outbound
When an MGMT_EV_DEVICE_CONNECTED event is reported back to the user space we will set the flags to tell if the established connection is outbound or not. This is useful for the user space to log better metrics and error messages.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Yu Liu <yudiliu@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20 |
|
#
ff02db13 |
| 03-Mar-2021 |
Daniel Winkler <danielwinkler@google.com> |
Bluetooth: Allow scannable adv with extended MGMT APIs
An issue was found, where if a bluetooth client requests a broadcast advertisement with scan response data, it will not be properly registered
Bluetooth: Allow scannable adv with extended MGMT APIs
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>
show more ...
|
Revision tags: v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
b4a221ea |
| 22-Jan-2021 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: advmon offload MSFT add rssi support
MSFT needs rssi parameter for monitoring advertisement packet, therefore we should supply them from mgmt. This adds a new opcode to add advertisement
Bluetooth: advmon offload MSFT add rssi support
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 <apusaka@chromium.org> Reviewed-by: Manish Mandlik <mmandlik@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Yun-Hao Chung <howardchung@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
Revision tags: v5.10 |
|
#
4d9b9528 |
| 03-Dec-2020 |
Daniel Winkler <danielwinkler@google.com> |
Bluetooth: Change MGMT security info CMD to be more generic
For advertising, we wish to know the LE tx power capabilities of the controller in userspace, so this patch edits the Security Info MGMT c
Bluetooth: Change MGMT security info CMD to be more generic
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 <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>
show more ...
|
#
12410572 |
| 03-Dec-2020 |
Daniel Winkler <danielwinkler@google.com> |
Bluetooth: Break add adv into two mgmt commands
This patch adds support for the new advertising add interface, with the first command setting advertising parameters and the second to set advertising
Bluetooth: Break add adv into two mgmt commands
This patch adds support for the new advertising add interface, with the first command setting advertising parameters and the second to set advertising data. The set parameters command allows the caller to leave some fields "unset", with a params bitfield defining which params were purposefully set. Unset parameters will be given defaults when calling hci_add_adv_instance. The data passed to the param mgmt command is allowed to be flexible, so in the future if bluetoothd passes a larger structure with new params, the mgmt command will ignore the unknown members at the end.
This change has been validated on both hatch (extended advertising) and kukui (no extended advertising) chromebooks running bluetoothd that support this new interface. I ran the following manual tests: - Set several (3) advertisements using modified test_advertisement.py - For each, validate correct data and parameters in btmon trace - Verified both for software rotation and extended adv
Automatic test suite also run, testing many (25) scenarios of single and multi-advertising for data/parameter correctness.
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>
show more ...
|
#
35302158 |
| 19-Nov-2020 |
Reo Shiseki <reoshiseki@gmail.com> |
Bluetooth: fix typo in struct name
Signed-off-by: Reo Shiseki <reoshiseki@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9 |
|
#
2f20216c |
| 11-Sep-2020 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
Bluetooth: Emit controller suspend and resume events
Emit controller suspend and resume events when we are ready for suspend and we've resumed from suspend.
The controller suspend event will report
Bluetooth: Emit controller suspend and resume events
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 <abhishekpandit@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
#
f0cfc486 |
| 11-Sep-2020 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
Bluetooth: Add suspend reason for device disconnect
Update device disconnect event with reason 0x5 to indicate that device disconnected because the controller is suspending.
Signed-off-by: Abhishek
Bluetooth: Add suspend reason for device disconnect
Update device disconnect event with reason 0x5 to indicate that device disconnected because the controller is suspending.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
#
346ce5b7 |
| 11-Sep-2020 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
Bluetooth: Add mgmt suspend and resume events
Add the controller suspend and resume events, which will signal when Bluetooth has completed preparing for suspend and when it's ready for resume.
Sign
Bluetooth: Add mgmt suspend and resume events
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 <abhishekpandit@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
Revision tags: v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
d5ea32da |
| 25-Aug-2020 |
Daniel Winkler <danielwinkler@google.com> |
Bluetooth: Add MGMT capability flags for tx power and ext advertising
For new advertising features, it will be important for userspace to know the capabilities of the controller and kernel. If the c
Bluetooth: Add MGMT capability flags for tx power and ext advertising
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 <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
show more ...
|
Revision tags: v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47 |
|
#
7fceb17c |
| 17-Jun-2020 |
Miao-chen Chou <mcchou@chromium.org> |
Bluetooth: Add definitions for advertisement monitor features
This adds support for Advertisement Monitor API. Here are the commands and events added. - Read Advertisement Monitor Feature command -
Bluetooth: Add definitions for advertisement monitor features
This adds support for Advertisement Monitor API. Here are the commands and events added. - Read Advertisement Monitor Feature command - Add Advertisement Pattern Monitor command - Remove Advertisement Monitor command - Advertisement Monitor Added event - Advertisement Monitor Removed event
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>
show more ...
|
#
4c54bf2b |
| 17-Jun-2020 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
Bluetooth: Add get/set device flags mgmt op
Add the get device flags and set device flags mgmt ops and the device flags changed event. Their behavior is described in detail in mgmt-api.txt in bluez.
Bluetooth: Add get/set device flags mgmt op
Add the get device flags and set device flags mgmt ops and the device flags changed event. Their behavior is described in detail in mgmt-api.txt in bluez.
Sample btmon trace when a HID device is added (trimmed to 75 chars):
@ MGMT Command: Unknown (0x0050) plen 11 {0x0001} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 ........... @ MGMT Event: Unknown (0x002a) plen 15 {0x0004} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0003} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0002} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Command Compl.. (0x0001) plen 10 {0x0001} [hci0] 18:06:14.98 Unknown (0x0050) plen 7 Status: Success (0x00) 90 c5 13 cd f3 cd 02 ....... @ MGMT Command: Add Device (0x0033) plen 8 {0x0001} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Device Added (0x001a) plen 8 {0x0004} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Device Added (0x001a) plen 8 {0x0003} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Device Added (0x001a) plen 8 {0x0002} [hci0] 18:06:14.98 LE Address: CD:F3:CD:13:C5:90 (Static) Action: Auto-connect remote device (0x02) @ MGMT Event: Unknown (0x002a) plen 15 {0x0004} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0003} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0002} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ............... @ MGMT Event: Unknown (0x002a) plen 15 {0x0001} [hci0] 18:06:14.98 90 c5 13 cd f3 cd 02 01 00 00 00 01 00 00 00 ...............
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>
show more ...
|
#
7e90de4a |
| 10-Jun-2020 |
Alain Michaud <alainm@chromium.org> |
Bluetooth: mgmt: read/set system parameter definitions
This patch submits the corresponding kernel definitions to mgmt.h. This is submitted before the implementation to avoid any conflicts in values
Bluetooth: mgmt: read/set system parameter definitions
This patch submits the corresponding kernel definitions to mgmt.h. This is submitted before the implementation to avoid any conflicts in values allocations.
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>
show more ...
|
Revision tags: v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40 |
|
#
a10c907c |
| 06-May-2020 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add support for experimental features configuration
To enable platform specific experimental features, introduce this new set of management commands and events.
Signed-off-by: Marcel Hol
Bluetooth: Add support for experimental features configuration
To enable platform specific experimental features, introduce this new set of management commands and events.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
show more ...
|
#
14a81bf0 |
| 06-May-2020 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare
Bluetooth: replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
show more ...
|