Bluetooth: host: Initial code for 5.2 features#23199
Bluetooth: host: Initial code for 5.2 features#23199jhedberg merged 10 commits intozephyrproject-rtos:masterfrom
Conversation
Vudentz
added
Feature
|
All checks are passing now. Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
Vudentz
force-pushed
the
bt5_2
branch
5 times, most recently
from
944c5a4 to
a73645d
Compare
Vudentz
force-pushed
the
bt5_2
branch
3 times, most recently
from
7b58c1a to
889a429
Compare
zephyrbot
added
the
area: Tests
tests/bluetooth/bsim_bt/edtt_ble_test_app/gatt_test_app/prj.conf
Outdated
Show resolved
Hide resolved
joerchan
left a comment
joerchan
left a comment
There was a problem hiding this comment.
Sorry for taking so long to post feedback.
I haven't looked too closely at all of the implementation yet, so posting the more shallow comments. Will continue to look.
|
Regarding the RFC tag. Is that for the API part? If so I think that part looks good. But it would be nice to get feedback from users who are expected to use this API as well. |
I can drop the RFC tag then, I was hoping to get more feedback but it looks like either there were no comments or people were busy with something else. |
@aescolar @Rasmus-Abildgren-Bose @carlescufi Any comments on the proposed API changes? |
|
I'm currently too busy to do a full review but have had a look at the API. I see no problem with these changes. |
|
@joerchan can you please test this on a complex application? |
Preferable against something that implements EATT already like BlueZ, but you will need to update the enable the kernel parts if you want to test ecred procedures as otherwise it connects L2CAP channel by channel, that said the features is marked as experimental exactly to give people the opportunity to test this themselves. |
|
@Vudentz My main concern was regression into ATT since some of the refactoring touches on common code. We have tested the nrf_desktop application in NCS with these changes to check for regressions. We haven't found any issues. I don't have anything to test with for the new features, so I will just go over the latest changes. |
I though the reason to add EDTT as part of CI was to extensively test ATT already, anyway now I have to resolve the conflicts you introduced with changes to the documentation which could have been avoided by just waiting this set to go in. |
This introduces new Enhanced Credit Based Flow Control PDUs and related definitions which were introduced in 5.2. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This replaces the use of tabs with spaces to align defines. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds the initial implementation of ECRED mode which can connect up to 5 channels simultaneously and is required by EATT. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This leaves only channels on the dynamic range to be offloaded to the system queue so ATT and EATT handling are handling in the same context. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds a callback to indicate when the stack has released all references to a given channel so the owner free up any resources associated with that. This is requires since EATT channels cannot rely on the destroy callback as it does not use a fixed channel like ATT. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds the definitions for Enhanced ATT along with new PDUs and UUIDs introduced in 5.2. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds support for EATT bearer which was introduced in 5.2, they work as extra channels to have GATT traffic, at the moment it is completely transparent to application when they are in use since the allocation happens automatically. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds support for ATT_MULTIPLE_HANDLE_VALUE_NTF, ATT_READ_MULTIPLE_VARIABLE_REQ and ATT_READ_MULTIPLE_VARIABLE_RSP. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This enables BT_EATT for shell samples so it can be build test by CI and gives user the ability of test it using shell commands. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds a new flag to track if the L2CAP channel is pending waiting for encryption to be changed to resume connecting. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
@Vudentz nrf_desktop is a HID mouse application. It has caught many regressions earlier which is why I wanted to test it now as well. EDTT test cases are good, but they test one thing at a time and are mostly functional test-cases. Some stress-testing is good as well. This is looking good to me. I only have the one question. |
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199). After \zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199). After PR zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199) because `bt_l2cap_chan_send` could return number of bytes sent. After PR zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199) because `bt_l2cap_chan_send` could return number of bytes sent. After PR zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199) because `bt_l2cap_chan_send` could return number of bytes sent. After PR zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199) because `bt_l2cap_chan_send` could return number of bytes sent. After PR zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (#23199) because `bt_l2cap_chan_send` could return number of bytes sent. After PR #67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`>= 0` was used when EATT support was implemented (zephyrproject-rtos#23199) because `bt_l2cap_chan_send` could return number of bytes sent. After PR zephyrproject-rtos#67528, `bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive value, but either 0 or negative value. Thus `>= 0` is not needed. It also confusing when reading code, especially when the same check is not implemented in other cases where underlying function `chan_send` is used. Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
10 participants
This add support for for the following features: