The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This commit does the following 2 changes:
1) The return value of k_mutex_lock has been modified to
be treated as a fatal error instead of a simple runtime error.
The reason for this is to avoid having to handle those cases,
and to treat those cases a fatal errors. The timeout for the
mutex should be long enough for any operation within the lock,
and if it isn't, then that should be treated as something that
needs to be fixed, as it is likely a bug. This is also the reason
why the timeout was kept, instead of using K_FOREVER.
2) Ensure that all log statements are done while the log isn't
locked.
The implementation should be reconsidered in terms of application
callbacks, as the current state, where we need to unlock and relock
the mutex so many times does not only risk resolving in cases where
wrong values are set, but is also not very readable nor performant.
Changes to the API will be done in a followup commit, as that requires
more significant changes.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
When an unicast initiator procedure or a commander broadcast
procedure is completed and we have handover enabled, the
parameters used need to be cleared before continueing.
This is due to the fact that the parameters are only cleared
on completion, rather than at initialization, and that the
initiator and commander parameters are in a union.
Not clearing the parameters could set some values to an
unknown/unexpected start value.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Add a user_data field to bt_ccp_call_control_client_cb. The
field is optional to enable via Kconfig. The field can be used
to provide additional context from the owner of the callback
structure, to the callbacks themselves.
This solves a memory use-after-free issue in the unit tests
where the values from the callback was accessed after they
were released, as the values were just stack allocated.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The usage of CHECKIF has been replaced with a regular
if. The reason for this is that higher layer may depend
on some of the checks defined by the API, and the higher
layers cannot do that properly if the checks can be
removed via a Kconfig option.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Rename variable 'ret' to 'err' in cmd_send_media() to align with
Zephyr coding conventions for error return values.
Signed-off-by: Mark Wang <yichang.wang@nxp.com>
Add shell command for testing BR/EDR inquiry scan parameters update.
Supports default parameter set and custom parameters via interval/
window/type arguments for inquiry scan configuration.
Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
Implement BR/EDR inquiry scan parameters update functionality with
new API bt_br_inquiry_scan_update_param(). Adds support for setting
inquiry scan interval, window and type via HCI commands. Includes
default parameter set for standard inquiry scanning.
Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
Implement BR/EDR page scan parameters update functionality with new
API bt_br_page_scan_update_param(). Adds support for setting page scan
interval, window and type (standard/interlaced) via HCI commands.
Includes predefined parameter sets for different Bluetooth versions
and use cases.
Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
This commit implements Class of Device (COD) test shell
functionality for Classic Bluetooth, supporting both
setting and retrieving COD from the controller.
Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
This commit implements Class of Device (COD) functionality for
Classic Bluetooth, supporting both setting and retrieving COD
from the controller by bt_br_write_cod and bt_br_read_cod.
Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
assigned true/false values, not 1/0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
As per Zephyr coding guideline #59, "operands shall not be of an
inappropriate essential type". This makes sure boolean variables are
initialized and used with proper essential type (true/false).
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Set the FCS option to BT_L2CAP_BR_FCS_16BIT for enhanced retransmission
mode in both L2CAP accept and connect paths to work around an
interoperability issue with iPhone devices.
The issue occurs when connecting to iPhone for PBAP or MAP profiles,
where the iPhone expects the 'No FCS' option to be applied but does
not include the 'No FCS' option in its L2CAP_CONFIGURATION_REQ packet.
Forcing 16-bit FCS ensures proper configuration negotiation.
Changes include:
- Set rx.fcs to BT_L2CAP_BR_FCS_16BIT in goep_l2cap_accept()
- Set rx.fcs to BT_L2CAP_BR_FCS_16BIT in
bt_goep_transport_l2cap_connect()
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Move state retrieval before error handling to ensure it's always
available for subsequent checks. Add a check to prevent executing
the callback when the AG connection is in a disconnected state.
This prevents potential use-after-free or invalid state access when
the callback is invoked after the AG has been disconnected, improving
the robustness of the notification work handler.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
