Implement readout protection for the STM32U5 / STM32L5 series.
Move the stm32u5 / stm32l5 flash register manipulation in
flash_stm32_option_bytes_write() to be called by the
flash_stm32_set_rdp_level().
Signed-off-by: Johannes Schuler <jschuler@testo.de>
The flash0 physical address in the node name did not
match the starting address in the reg property. This
part implements 352KB code SRAM starting at 0xC0000.
Signed-off-by: Scott Worley <scott.worley@microchip.com>
The test_sem_multiple_threads_wait test spawns multiple threads
to wait on one semaphore. The test itself loops twice, and in
each iteration it calls k_thread_create() to create new threads
but without joining the threads at the end of the loop. With
SMP, it is possible for the threads to still be running on
other CPUs when k_thread_create() is called on the second
iteraion. This overwrites the data inside the thread object.
When other CPUs finishes with those threads and try to clean up
the threads, they now have incorrect data (e.g. stack pointer)
which may result in CPU exception. So we need to make sure all
running threads have stopped running before starting the second
iteration.
Signed-off-by: Daniel Leung <daniel.leung@intel.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>
Add a section explaining why "detached HEADS" / "git checkout
--detach" were chosen as the default "west update" behavior, and
document some common ideas for what to do if you're actively
developing in a project. Reference it from the update procedure
detailed steps, so users have a hope of finding it when they wonder
"why" while reading that documentation.
Signed-off-by: Martí Bolívar <mbolivar@oss.qualcomm.com>
Add a helper function to check the lock status of the QSPI-FIU
bus controller mutex. This is useful for debug assertions and
verifying exclusive access in high-level drivers.
Signed-off-by: Firas Sammoura <fsammoura@google.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>
For drivers that were making mentions to master/slave terminology in
their comments or code without no reason to do so (i.e. no API in their
HAL is using such terminology), the terminology was dropped and replaced
with controller/peripheral terminology.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
I2S bus specification 3.0 [1] updated terms "Master" and "Slave" to
"Controller" and "Target". This rename macros using these terms and
deprecates old names.
[1] https://www.nxp.com/docs/en/user-manual/UM11732.pdf
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Have bbram shell commands use the new SHELL_HELP macro
Also fix the syntax for "read" command as it wasn't
correctly indicating that count cannot be specified
without address.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Removing cpu0 reference from mcxw72 target
as only cpu0 should be targeted on this device.
Signed-off-by: Emilio Benavente <emilio.benavente@nxp.com>
Signed-off-by: Andrej Butok <andrey.butok@nxp.com>
The unclear semantics of CONFIG_WDT_DISABLE_AT_BOOT have now been set in
stone, but this change will affect users which relied on a specific
interpretation of CONFIG_WDT_DISABLE_AT_BOOT which doesn't match the
semantics that have been agreed upon.
Document this change in the migration guide, indicating that watchdogs must
now be configured explicitly by the applications if required.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
There are many drivers which control a disabled-by-default watchdog timer
but take the liberty of selecting HAS_WDT_DISABLE_AT_BOOT and interpreting
WDT_DISABLE_AT_BOOT=n as "enable the timer", which does not correspond to
the semantics of this option.
Update all such drivers to no longer select HAS_WDT_DISABLE_AT_BOOT and
ignore the WDT_DISABLE_AT_BOOT option.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
