Change comment from "increasing" order to "decreasing"
since the 0th indexed Pstate must have the highest
threshold.
Signed-off-by: Sean Kyer <sean.actor@gmail.com>
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>
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>
Instead of calling the low-level function from usbh_ch9.c, call the
higher level function from usbh_device.c to update the address,
making sure that the udev->address and udev->state are updated
appropriately.
Signed-off-by: Josuah Demangeon <josuah.demangeon@nordicsemi.no>
To complement usbh_req_set_address(), add a matching function
usbh_device_set_address() that also takes care of updating the data
structures.
Signed-off-by: Josuah Demangeon <josuah.demangeon@nordicsemi.no>
NVS writes an entry by first programming the data area and then writing
the corresponding ATE. If a power loss occurs after the data has been
written but while the ATE is being programmed, and the remaining space
in the sector is only large enough for a single ATE, the ATE may end up
partially written.
1) Power loss while writing the last data ATE, leaving only space for
a delete ATE but no space for additional data entries:
[ data ][ data ][ erase ][ ATE ][ ATE ][ erase ] (sector end)
^^^
In this cases, nvs_startup() scans the sector and fails to find any
erased space usable for data writes, causing failed to mount.
[ data ][ data ][ erase ][ ATE (Invalid) ][ ATE ][ erase ]
^ ^
ate_wra
data_wra
The sector is logically exhausted andshould be closed and garbage
collected.
Detect this condition during startup. If no erased space exists after
the last ATE write, explicitly close the sector and trigger garbage
collection to restore a writable sector.
This completes the missing recovery path for power-loss scenarios
where a sector becomes effectively full due to ATE writes.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
WHen running the shell devmem dump command and CONFIG_MMU is enabled, the
virtual memory wasn't unmapped.
Call the device_unmap function to cleanup virtual memory resources.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
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>
According to the USB CDC 1.2 specification, section 4.6, the value of
bInterfaceSubClass for the data interface should be 0.
Signed-off-by: Jay Beavers <jay@tolttechnologies.com>
Origin: Original
Fixes: zephyrproject-rtos/zephyr#103444
The get_entry() function uses IS_ENABLED(CONFIG_BINDESC_READ_FLASH) in
an if statement to guard code that accesses struct members (flash_device,
buffer) which are only defined when CONFIG_BINDESC_READ_FLASH is enabled.
While IS_ENABLED() correctly evaluates to 0 when the config is disabled,
the C compiler still performs type-checking on all code paths before
optimization can eliminate the dead branch. This causes a compile error:
error: 'struct bindesc_handle' has no member named 'flash_device'
error: 'struct bindesc_handle' has no member named 'buffer'
Fix by using preprocessor #if directive instead of runtime if statement.
This ensures the flash-specific code is excluded during preprocessing
when CONFIG_BINDESC_READ_FLASH is not enabled.
Signed-off-by: Jay Beavers <jay@tolttechnologies.com>
Flag the ECM and NCM interfaces as supporting promisc mode. There's no
filtering really so enabling promisc is a noop but pretending to have
support is needed to allow these to be added to a bridge.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
