There was a semaphore in hci_core which was given to early when
receiving the BT_HCI_EVT_NUM_COMPLETED_PACKETS message from the
controller. This would sometimes cause an assert to happen in
function hci_num_completed_packets, where there would arise a
mismatch in the bookkept count, and actually stored nodes. More
concretely, due to premature semaphore giveing, the tx_pending node
would be have been removed in another context before it could be
fetched and moved to complete list in this function.
Signed-off-by: Fredrik Danebjer <frdn@demant.com>
The current frequency of 16 MHz has been observed to result in
communications errors on a nRF5340DK. Since the LoRa PHY bitrate is
measured in kbps, there is no throughput implications from this change.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Currently, GPIO16/17 are supported for Ethernet phy
clock out, but some boards are also using GPIO0.
This change allows GPIO0 to be configured.
Signed-off-by: Cliff Brake <cbrake@bec-systems.com>
Picolibc's retargetable locking is based upon having the user own the lock
type (struct __lock, along with typedef struct __lock *_LOCK_T), and then
having the picolibc internal code only refer to this type via the _LOCK_T
pointer typedef, leaving the actual struct undeclared there.
Zephyr wants to use 'struct k_mutex' for this type; the initial picolibc
port handled this by trying to redefine the picolibc locking to use 'void
*' instead of 'struct __lock *' by including '#define _LOCK_T void
*'. Which 'works' as long as the Zephyr code doesn't actually include
picolibc's sys/lock.h.
A recent picolibc change to support POSIX stdio locking has picolibc's
stdio.h including sys/lock.h, which breaks Zephyr's hack.
To fix this, create a real 'struct __lock' type as
struct __lock { struct k_mutex m; };
Define all of the required picolibc locking API with this real type,
referring to the mutex inside without needing any casts.
This required switching the definition of the C library global lock from
K_MUTEX_DEFINE to the open-coded version, STRUCT_SECTION_ITERABLE_ALTERNATE
so that it has the correct type and still lands in the same elf section.
The only mildly inappropriate code left is that lock are allocated using
k_object_alloc(K_OBJ_MUTEX), which "works" because the size of 'struct
__lock` will exactly match the size of 'struct k_mutex' because of C's
struct allocation rules.
Signed-off-by: Keith Packard <keithp@keithp.com>
The stm32mp135f_dk board embeds an I/O expander to get access
to more I/O. Led 3 (green) and Led 4 (orange) are accessible via this
I/O expander.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
The stm32mp135f_dk board has 3 i2c instances enabled and feature a
480x272 panel controlled via the LTDC.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
The non-secure LTDC plane has its own register for clock gating hence
add an entry to control this.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Replace the usage of __HAL_LTDC_RELOAD_CONFIG which is a legacy
API with __HAL_LTDC_RELOAD_IMMEDIATE_CONFIG
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
When using one set of environment variables for multiple
cores compilation, we also need to supply the core name in
linker flags. So add that to TOOLCHAIN_LD_FLAGS.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In case of the st,stm32-xspi-nor compatible
new property and node definitions will requires new macro
to get the external NOR flash base address and size
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This PR defines the "st,stm32-xspi-nor" compatible Node
in conformance to the DTS specifications
Includes the size property (in Bits) of the external NOR device
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This PR defines the "st,stm32-xspi-nor" compatible Node
and the "st,stm32-xspi-psram" compatible Node
in conformance to the DTS specifications
Includes the size property (in Bits) of the external memory device
Signed-off-by: Francois Ramu <francois.ramu@st.com>
New property of the st,stm32-xspi-psram compatible gives
the external PSRAM memory in bits.
The property of the st,stm32-xspi compatible gives
the external PSRAM memory base address
Signed-off-by: Francois Ramu <francois.ramu@st.com>
New property of the st,stm32-xspi-nor compatible gives
the external NOR flash in bits.
The property of the st,stm32-xspi compatible gives
the external NOR flash base address
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The st,stm32-xspi compatible is defining the reg property
with the register address and size at first index
followed by the external memory base address and max allocated
xspi1 is addressing max 256 MBytes from 0x90000000
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The st,stm32-xspi compatible is defining the reg property
with the register address and size at first index
followed by the external memory base address and max allocated
size. For the stm32N6 serie,
xspi1 is addressing max 256 MBytes from 0x90000000
xspi2 is addressing max 256 MBytes from 0x70000000
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Uses sub-partitions to allow having a dedicated secure and
non-secure partition area in flash partitions, which also allows
the main application slot to be extended when TF-M is not in use
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Align all sensor drivers that are using stmemsc (STdC) HAL i/f
to new APIs of stmemsc v2.9.1.
Requires https://github.com/zephyrproject-rtos/hal_st/pull/25
Signed-off-by: Armando Visconti <armando.visconti@st.com>
