Microchip MEC5 SoCs use the same Synopsys DWC_mipi_i3c IP as other
supported platforms, wrapped with XEC-specific interrupt routing and
a HOST_CFG port-select register. Reuse the existing DW I3C driver by
adding a microchip,xec-i3c compatible and binding for MEC5 I3C nodes.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.com>
Assisted-by: Claude:claude-opus-5
Convert the MIPS CP0 timer to system_timer_generic.h. The CP0 Count
counter with its Compare register is a COMPARE backend, and the first
converted driver whose counter actually wraps during operation: on
32-bit MIPS TIMER_CORE_COUNTER_WIDTH defaults to the native 32 bits, so
the core masks every delta at the 2^32 boundary.
Compare raises the interrupt only on Count == Compare, so an
already-past target is missed until Count wraps all the way around. That
is the COMPARE_EXACT backend: the core writes the register through its
verify loop, replacing the driver's own bump-and-retry and its MIN_DELAY
floor in both set_timeout and the ISR. Writing Compare also clears the
interrupt.
The core now owns the tick accounting and the locking, so the driver's
private spinlock is gone. This also fixes a slow drift: the driver
resynced its baseline to the raw count each ISR and discarded the
sub-tick remainder, where the core keeps the baseline tick-aligned.
timer_api and context pass on qemu_malta, which joins the sloppy-idle
timer_api variant.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
A down-counter reloaded from the preload register that interrupts at zero
and does not free-run, so a RELOAD backend. The counter the core reads is
synthesized, the reloads consumed so far plus what the one in flight has
counted down, declared 28 bits wide like the hardware. That read touches
state the ISR and the reload path also write, so the core is told the read
is not atomic and serialises the public getters, as the driver's own getter
did.
The core takes over the tick accounting, which removes the split between
the tickless and ticked builds: last_announcement, two ISR variants, two
sys_clock_elapsed() variants and the deadline computation all collapse into
one ISR that accounts the consumed reload and announces, plus a reload
primitive that folds in what a replaced reload had counted.
The same overflow as in the Realtek driver was here too: the tickless ISR
reloaded MAX_TICKS * CYCLES_PER_TICK, which is TIMER_MAX rounded down and
then multiplied again, wrapping past the counter's 28 bits. It now reloads
the counter's maximum. sys_clock_elapsed() likewise took the absolute value
of a difference computed backwards; the core computes it once, from the
counter.
sys_clock_idle_enter() takes over stopping the timer, the one place it is
safe: the CPU is on its way to sleep, so nothing is left to read a
synthesized count that stops with it, and sys_clock_idle_exit() starts it
again. The magic tick value that used to request it could arrive with the
CPU still running, outside any locked section.
Build-tested on mec172xevb_assy6906, tickless and tickful, with and without
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The counter and the alarm are two different timers here, which the core
keeps apart. The cycle domain is the free-running 32-bit timer, counting
down from 0xffffffff and read back inverted; the wakeup is a separate
24-bit event timer, a one-shot countdown. That makes it a RELOAD backend
whose range is bounded by the event timer rather than by the counter. Both
select the same clock, so the core's cycles are the event timer's without
conversion.
The core takes over the tick accounting: last_announced_hw_cnt, last_ticks
and last_elapsed go, and with them the deadline computation and the clamp
that turned a tick count into an event-timer count. What is left is the
register sequence in timer_driver_set_reload() and an ISR that
acknowledges, re-arms the one-shot event timer for a ticked kernel, and
announces. sys_clock_set_timeout(), sys_clock_elapsed() and
sys_clock_cycle_get_32() come from the core, the last in the same domain
the driver reported. HW_CNT_PER_SYS_TICK and EVEN_TIMER_MAX_CNT_SYS_TICK
go with them, the one cycles-per-tick user left, the one-tick event timer
a ticked kernel starts at init, reading TIMER_CORE_CYC_PER_TICK instead.
IDLE_BLOCK_TIMER_TICKS spelled the same microsecond-to-cycle division out
by hand and becomes k_us_to_cyc_ceil32().
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE used to leave the event timer disabled
once the timeout queue drained. The core arms the longest span the event
timer can hold instead; sys_clock_no_timeout() is not implemented.
Build-tested on it8xxx2_evb, tickless and tickful, with and without
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The counter and the alarm are two different timers here, which the core
keeps apart. The cycle domain is the free-running 32-bit timer, counting
down from 0xffffffff and read back inverted; the wakeup is a separate
24-bit event timer, a one-shot countdown. That makes it a RELOAD backend
whose range is bounded by the event timer rather than by the counter. Both
select the same clock, so the core's cycles are the event timer's without
conversion.
The core takes over the tick accounting: last_announced_hw_cnt, last_ticks
and last_elapsed go, and with them the deadline computation and the clamp
that turned a tick count into an event-timer count. What is left is the
register sequence in timer_driver_set_reload() and an ISR that
acknowledges, re-arms the one-shot event timer for a ticked kernel, and
announces. sys_clock_set_timeout(), sys_clock_elapsed() and
sys_clock_cycle_get_32() come from the core, the last in the same domain
the driver reported. HW_CNT_PER_SYS_TICK and EVEN_TIMER_MAX_CNT_SYS_TICK
go with them, the one cycles-per-tick user left, the one-tick event timer
a ticked kernel starts at init, reading TIMER_CORE_CYC_PER_TICK instead.
The ticked path announced MS_TO_COUNT(HW_CYCLES_PER_SEC, 1) ticks per
interrupt, a cycle count where a tick count was wanted, so a ticked kernel
on this driver ran its uptime fast by that factor. The core announces what
the counter says.
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE used to leave the event timer disabled
once the timeout queue drained. The core arms the longest span the event
timer can hold instead; sys_clock_no_timeout() is not implemented.
Build-tested on it51xxx_evb, tickless and tickful, with and without
CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The free-running 64-bit TSC with an absolute deadline (the TSC_DEADLINE
MSR, or the local APIC timer ICR in one-shot mode as the fallback) is a
COMPARE_ORDERED backend. The driver keeps timer_driver_cycle_get()
(rdtsc) and timer_driver_set_compare() (set_trigger), and the core takes
over the tick accounting, the deadline math, the range clamp and the
announce. The last_cycle baseline and the sys_clock_elapsed() /
sys_clock_set_timeout() tick math go, the ISR reduces to an announce,
and smp_timer_init() keeps copying CPU0's LVT to each secondary.
The TSC is 64 bits wide even on a 32-bit build, so the driver states
that width; the old code divided its deltas at the native register
width.
The deadline arm range narrows from the driver's former three-quarter
span to the core's default half span, which reserves the upper half as
IRQ-latency headroom so a late announce of a maximum-length arm still
yields an in-range delta.
The set_timeout() guard that pinned a deadline to UINT64_MAX when the
computed deadline wrapped the 64-bit TSC goes; the core's range clamp
bounds the arm instead.
Built on qemu_x86_64 and qemu_x86 with the TSC deadline comparator, and
on qemu_x86_64 with the APIC_TIMER_TSC ICR fallback.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
If errata 16 is present mailbox (vevif) driver need to start as soon
as possible, just after the launcher. 0 priority level is common so
there might a delay between starting the launcher and initializing the
mailbox driver for receiving events from the VPR core. When errata 16
is present, less common level is used to minimize the time when
events from VPR could get lost.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
This mailbox is used only for communicating with VPRs started by
the VPR launcher. Some SoCs has an error where events from VPR triggered
before mailbox initialization is completed might be lost. On the other
hand mailbox driver cannot be started before VPR as it accesses registers
which are powered up by the launcher. We need to minimize the time between
VPR launching and mailbox initialization. It is acheived by using adjacent
priorities.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
The baudrate divisor calculation should take the fractional parameter
into account when a DLF-capable UART is used. Otherwise non-optimal
integer divisors can be derived, especially for low pclk or high
baud_rate values.
Signed-off-by: Andreas Weissel <andreas.weissel@synaptics.com>
SysTick is an auto-reload 24-bit down-counter, so a RELOAD backend. The
driver keeps its hardware-specific parts, the synthesized cycle count
with COUNTFLAG-based wrap detection and the LOAD reprogram with its
drift compensation. The core takes over the tick accounting:
announced_cycles and last_elapsed go, along with the deadline-to-reload
conversion, the range clamp and the announce. The 24-bit LOAD caps the
arm range, and the existing min_delay becomes the reload floor.
The driver carries no cycles-per-tick of its own. The reload floor is
already a cycle count, so the only remaining use for that value is the
one-tick LOAD at init and on the low-power restart, which reads the
core's TIMER_CORE_CYC_PER_TICK. The "tickless does nothing" pragma goes
too, the core build-asserting a non-zero cycles-per-tick.
The synthesized count is 32 bits whatever
CONFIG_CORTEX_M_SYSTICK_64BIT_CYCLE_COUNTER says. That option used to
widen it to 64, putting 64-bit arithmetic on every path to serve one: a
low-power sleep can outrun a 32-bit count, and routing it through the
counter was the only way to announce it. sys_clock_idle_exit() hands
that span to the core directly instead, advancing the counter across it
so the two stay in step, so only that path pays for the wider math. The
option is left advertising sys_clock_cycle_get_64() to the rest of the
system, which is all it was ever about.
The counter is no longer stopped when the timeout queue drains. That is
what CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE did here, and it froze
k_cycle_get_32() under a running thread. The core arms the longest
reload the hardware can hold instead, and the stop moves to
sys_clock_idle_enter(K_TICKS_FOREVER), where the CPU is on its way to
sleep and sys_clock_idle_exit() is guaranteed to restart it.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Assert CS with zero-byte transaction since BLE HCI SPI(hci_spi_st.c) driver
relies on zero-byte transaction for asserting CS.
It fixes the SPI communication for radio co-processors (RCP).
Signed-off-by: Ali Hozhabri <ali.hozhabri@st.com>
That is the only driver in the tree that uses odd flags from the
bitfield in struct udc_ep_stat. udc_ep_stat may have RMW bugs due to
bitfields modified from different contexts. The use of odd bitfield is
safe in this driver, as all writes are in the ISR handler.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
_i2c_set_peri_divider() called ifx_cat1_utils_peri_is_fract_div() twice to
gate two separate branches. Compute it once into a named boolean and reuse
it, making the fractional-versus-integer divider handling easier to follow.
No functional change.
Assisted-by: AI (GitHub Copilot)
Signed-off-by: Bill Waters <bill.waters@infineon.com>
The clock_peri_group data member and the PERI_INFO() initializer macro
that sets it are write-only in this driver: the member is populated from
devicetree at build time but is never read anywhere in the driver. The
divider source frequency is reconstructed directly from the running
clock (current_output * current_ratio), so the peripheral-group index is
not needed here.
Remove the member, the PERI_INFO() macro definition, and its two
invocations in I2C_PERI_CLOCK_INIT().
Assisted-by: AI (GitHub Copilot)
Signed-off-by: Bill Waters <bill.waters@infineon.com>
ifx_cat1_i2c_init() always brought the controller up at I2C_SPEED_STANDARD,
ignoring the devicetree "clock-frequency" property. A controller therefore
came up at 100 kHz regardless of the configured rate, and an explicit
i2c_configure() call was required to reach the requested speed.
Map the devicetree clock-frequency (already stored in
config->master_frequency) to a bitrate and pass it to
ifx_cat1_i2c_configure() at init so the bus is usable at the configured
rate without an i2c_configure() call. Move the i2c-priv.h include out of
the CONFIG_I2C_INFINEON_BUS_RECOVERY guard since i2c_map_dt_bitrate() is
now needed unconditionally.
Measured SCL on kit_pse84_eval (m33) with clock-frequency set to FAST and
no i2c_configure() call from the application:
Before: 93 kHz (STANDARD - property ignored)
After: 362 kHz (FAST - matches the configured rate)
Assisted-by: AI (GitHub Copilot)
Signed-off-by: Bill Waters <bill.waters@infineon.com>
The Infineon CAT1 I2C driver only programmed the SCB oversampling-clock
divider on PSoC 4. On every other CAT1 family the runtime divider was
never set, so a STANDARD, FAST or FAST_PLUS configuration all ended up
producing the same SCL frequency (whatever the static devicetree divider
happened to yield) instead of the requested data rate.
Replace the dead USE_I2C_SET_PERI_DIVIDER path and the PSoC 4-only
_i2c_set_peri_divider_psoc4() with a single _i2c_set_peri_divider()
compiled for all families. It maps the requested data rate to the SCB
oversampling-clock window, reconstructs the divider source frequency
(source = current_output * current_ratio, which is independent of the
family's HFCLK-to-peripheral-group routing), programs the integer or
fractional peripheral divider, and lets Cy_SCB_I2C_SetDataRate() derive
the SCL low/high phases. The divider is already running (it feeds the
SCB), so the value change follows the disable -> set -> enable sequence
the DIV_CMD register requires, and the Cy_SCB_I2C_SetDataRate() return is
checked so an unachievable rate is reported. The routine now returns a
negative errno on failure so ifx_cat1_i2c_configure() can propagate the
error.
Use the ifx_cat1_utils_peri_pclk_get_divider(),
ifx_cat1_utils_peri_pclk_get_frac_divider(),
ifx_cat1_utils_peri_pclk_disable_divider() and
ifx_cat1_utils_peri_is_fract_div() clock-control helpers to read back the
current divider ratio, disable the divider before reprogramming it, and
select the integer or fractional divider path by type instead of an
unclear block bitmask at the call sites.
Measured SCL on kit_pse84_eval (m33) after the change: STANDARD 100 kHz,
FAST 362 kHz, FAST_PLUS 862 kHz. Before the change all three speeds
produced the same rate regardless of the requested speed.
Assisted-by: AI (GitHub Copilot)
Signed-off-by: Bill Waters <bill.waters@infineon.com>
Add support for STM32H5E/F line SoCs: in particular, the power
initialization sequence for OTG_HS usage was incomplete.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Add code to enable automatic trimming of the HSI48 clock using USB SOF
interrupts using the built-in Clock Recovery System (CRS).
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
The BT_HCI_RAW_H4 and BT_HCI_RAW_H4_ENABLE Kconfig options lost their
last code references in commit 26d97164be ("Bluetooth: HCI: Use H:4
encoding for buffers"), which made the HCI raw layer use H:4 packet
encoding for all buffers unconditionally. Since then setting these
options has had no effect.
Remove the option definitions, the stale references in the sample
configurations, as well as a dead conditional default in the
BT_DRV_RX_STACK_SIZE option. Document the removal in the release
notes; since the options have been no-ops for several releases and
were never part of a deprecation cycle, there is no migration to
describe beyond dropping them.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Mechanism of early interrupt handling introduced for
nRF54L errata 16 can be used even if the anomaly
itself is not present on a chip.
It can solve the issue of missed events from early
booting VPR core.
Signed-off-by: Michał Stasiak <michal.stasiak@nordicsemi.no>
Remove the duplicated reference switch by wrapping
adc_emul_ref_get() from adc_emul_get_ref_voltage().
Assisted-by: Cursor:grok-4.5
Signed-off-by: Lasse Fröhner <lasse@starcopter.com>
Allow drivers to expose a runtime millivolt scale for any
adc_reference via optional ref_get. adc_ref_internal() becomes a
wrapper; adc_raw_to_*_dt prefers adc_ref_get() and falls back to
channel DT zephyr,vref-mv on failure.
Update adc_emul and tests accordingly.
Tested with: west twister -T tests/drivers/adc/adc_emul -p native_sim
Assisted-by: Cursor:grok-4.5
Signed-off-by: Lasse Fröhner <lasse@starcopter.com>
Wire emulator INTERNAL reference storage through the optional getter,
so host tests can exercise dynamic adc_ref_internal() via
adc_emul_ref_voltage_set().
Tested with: west twister -T tests/drivers/adc/adc_emul -p native_sim
Link: https://github.com/zephyrproject-rtos/zephyr/issues/113971
Assisted-by: Cursor:grok-4.5
Signed-off-by: Lasse Fröhner <lasse@starcopter.com>
Implement suspend, resume and remote wakeup. Make sof_enable callback a
no-op because controller automatically handles SOF generation when the
port is not suspended.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
If GPPI is using IPC communication then delay the initialization of an
UARTE instance which is using GPPI connection after GPPI is initialized
which happens after IPC service is setup.
Signed-off-by: Krzysztof Chruściński <krzysztof.chruscinski@nordicsemi.no>
Implemented get_iface_caps() in NXP wifi driver. It will check net
interface capability and return corresponding bitmask of
BIT(enum wifi_nm_iface_type).
Signed-off-by: Hui Bai <hui.bai@nxp.com>
Enable the on-board self-capacitive touch electrode E2 on
frdm_mcxa577 by wiring up the existing nxp,tsi-input driver,
following upstream commit that added TSI to the mcx_n9xx/n5xx boards.
Add a tsi0 node to the shared MCXA5x SoC devicetree (base offset
0xc3000, End-of-Scan / Out-of-Scan IRQs 124/125, MCUX_TSI_CLK),
disabled by default. On the board, add the TSI0_CH0 (P5_3) pinctrl
group, enable &tsi0 mapping E2 -> INPUT_KEY_A, set up the TSI clock
in board_early_init_hook (attach kFRO_HF_DIV_to_TSI0, divider 4),
and mark tsi as supported.
The clock_control mcux_syscon driver previously enabled only the
MCXN TSI gate (kCLOCK_Tsi). MCXA uses kCLOCK_GateTSI0, so make the
gate enable family-aware; without it the peripheral is unclocked and
the driver's init-time calibration faults the CPU before the console
comes up.
Tested on frdm_mcxa577 with samples/subsys/input/input_dump:
touching E2 emits INPUT_KEY_A press/release events.
Signed-off-by: Peter Wang <chaoyi.wang@nxp.com>
channel_mask is a uint32_t, so the driver can only address TSI
channels 0..31 regardless of how many the hardware exposes. On SoCs
with more than 32 channels (e.g. MCXA577 has 70) two problems arise:
BIT_MASK(FSL_FEATURE_TSI_CHANNEL_COUNT) overflowed the 32-bit shift in
the mask range check, and the per-channel state array was sized to the
full hardware count, wasting RAM on channels that can never be used.
Introduce MCUX_TSI_MAX_CHANNELS = MIN(FSL_FEATURE_TSI_CHANNEL_COUNT,
32) and use it for the state array, the mask range check, the scan
round-robin bound, and the calibration loop. This fixes the shift
overflow and drops the wasted per-channel state (about 300 B of RAM
on MCXA577).
Built samples/subsys/input/input_dump for frdm_mcxa577.
Signed-off-by: Peter Wang <chaoyi.wang@nxp.com>
Cortex-A53 SBC on the Broadcom BCM2710 (BCM2837 die). Adds the
soc/brcm/bcm2710 SoC with the native BCM283x interrupt controllers
(no GIC), booting single-core with the mini-UART console at 115200.
Signed-off-by: Jonathan E. Peace <jep@alphabetiq.com>
Exposes the FPGA System ID build-info ROM (board / product / git
data) through the standard Zephyr OTP API as a read-only device.
otp_read() returns the raw ROM bytes; knowledge of the ROM format is
intentionally left to the consumer.
CONFIG_OTP_ADI_AXI_SYSID is auto-selected when
DT_HAS_ADI_AXI_SYSID_ENABLED.
Signed-off-by: Iustin Stolniceanu <stolniceanuiustin@gmail.com>
The RTC is a free-running counter that z_nrf_rtc_timer_read() extends to
64 bits in software, plus an absolute compare, so a COMPARE_ORDERED
backend: compare_set() raises the interrupt straight away for a target the
counter has already passed, and the core's single write is enough. The
counter width is declared as the extended one, 64 bits, while the arm
range stays the driver's own MAX_CYCLES, half the 24-bit counter span,
because that bound comes from the compare register rather than from the
count the core reads.
The core takes over the tick accounting. last_count, last_elapsed and the
cycle-to-tick math go with it, and so do sys_clock_set_timeout(),
sys_clock_elapsed() and sys_clock_cycle_get_32(), which the core emits.
What is left of the timeout handler is the anchor update and the announce.
sys_clock_no_timeout() stays. It does something the arming path cannot:
release sys_busy, which keeps z_nrf_rtc_timer_trigger_overflow() out of
the way while a deadline is pending. The core's default would park the
compare the same distance out but leave that flag set. This also replaces
the old magic tick value in sys_clock_set_timeout(), where a timeout
further out than the announce range arrived as that same value and was
indistinguishable from having none.
Not reprogramming at all in the hook would be the natural improvement, the
compare already in place covering the counter wrap, but that is a
behaviour change and is left for the driver's maintainers.
timer_api, context and sleep pass on nrf52_bsim, which runs this driver
against a model of the RTC, and timer_api passes on nrf5340bsim,
including the sloppy-idle variant. Also build-tested on nrf52840dk,
nrf5340dk and nrf9160dk.
The tickful configuration fails on nrf52_bsim, as it does on upstream
main, so that is not a regression from this change.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
drv_rx_done() took the length byte from the start of the RF core's receive
entry and immediately used it as an index twice:
len = drv_data->rx_data[i][0];
status = drv_data->rx_data[i][len--];
rssi = drv_data->rx_data[i][len--];
That byte is the over-the-air SUN-FSK PHR and is not validated. len == 0
makes the first read index rx_data[i][0], wrapping len to 255, so the
second read lands at rx_data[i][255] - 125 bytes past the 130-byte
(IEEE802154_MAX_PHY_PACKET_SIZE + 3) receive row - and leaves len at 254,
which is then used as the length for net_pkt_rx_alloc_with_buffer() and
net_pkt_write(), copying ~124 bytes of adjacent memory into a packet
delivered to the network stack.
With CONFIG_IEEE802154_L2_PKT_INCL_FCS the same wrap is an out-of-bounds
write: the CRC append does sdu[len++] twice, storing two bytes past the
row for a sufficiently large len.
Reject a length that would underflow the post-decrements or exceed the
receive buffer, and recycle the entry, mirroring the guard added to the 2.4
GHz sibling driver in "drivers: ieee802154: cc13xx_cc26xx: fix short-frame
path reaching net_recv_data".
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Commit "drivers: ieee802154: cc13xx_cc26xx: reject short RX frames
before len--" rejected RX frames with len < 4 before the two
post-decrements that would otherwise underflow uint8_t, but jumped to a
label placed after the packet allocation and before the packet is handed
to the network stack:
next_entry:
drv_data->rx_entry[i].status = DATA_ENTRY_PENDING;
net_pkt_set_ieee802154_lqi(pkt, lqi);
...
net_recv_data(drv_data->iface, pkt);
Taking the goto therefore reached net_pkt_set_ieee802154_lqi() and
net_recv_data() with pkt uninitialised on the first loop iteration, or
stale on later ones - in which case the packet had already been passed
to the net stack and unreferenced, making this a use-after-free that a
short frame could trigger remotely.
Recycle the RX entry and continue the loop instead, matching how the
DATA_ENTRY_UNFINISHED branch below already handles a discarded entry,
and drop the label.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The RX done handler post-decremented len twice then subtracted 2 for FCS.
With len < 4 the uint8_t underflows, producing a huge length passed to
net_pkt_rx_alloc_with_buffer. Reject frames with len < 4 before the
post-decrement operations.
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The CC1200 radio can supply a pkt_len of 0-255 but IEEE 802.15.4 limits
PHY packets to 127 bytes. verify_rxfifo_validity() only checked the lower
bound; values above 127 reached net_pkt_rx_alloc_with_buffer() unclamped.
Add the upper bound check against IEEE802154_MAX_PHY_PACKET_SIZE.
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The PHR is used to compute len = raw[0] - IEEE802154_FCS_LENGTH, bounded
only by __ASSERT_NO_MSG, which compiles out at CONFIG_ASSERT=n. Add the
lower bound before the subtraction and a runtime length check.
Note the ESP-IDF HAL drops frames whose FCS does not validate, and a frame
declaring fewer than two PHR bytes has no room for an FCS, so the wrap may
not be reachable in practice; the bound costs one comparison and does not
depend on that argument holding.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The driver subtracts the FCS length from the radio-reported length and then
bounds the result with __ASSERT_NO_MSG alone, which compiles out at
CONFIG_ASSERT=n - the production default. A length below the FCS size
wrapped to ~254 and drove the packet allocation and copy.
Add the lower bound before the subtraction and a runtime length check,
matching what the nrf5 driver already does.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The ACK length reported by the NBU was memcpy'd into a fixed
rx_ack_data[IEEE802154_MAX_PHY_PACKET_SIZE] buffer with no bound.
Drop an ACK that does not fit rather than copying past the end of the
buffer; a zero length tells mcxw_tx() that no ACK was received.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The frame-length register was used raw. MCR20A_RX_FRM_LENGTH_MASK is
defined but was never applied, and there was no lower bound, so len - 2
wrapped to ~254 and drove read_rxfifo_content(), which reads into the first
net_buf fragment only - overflowing that fragment.
Apply the mask, reject a length below the FCS size, and check the fragment
tailroom before the FIFO read.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The call site only checked that the radio-reported length was non-zero, so
a length below KW41Z_FCS_LENGTH underflowed pkt_len = len - FCS_LENGTH and
drove an oversized packet allocation and copy.
Reject such a length, and check the tailroom of the first net_buf fragment
before the copy loops, which write into that fragment only.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Some Renesas RA USBFS variants only have 5 pipes with a different
pipe layout compared to the standard variant:
- Pipe 0: control transfer
- Pipes 4-5: bulk transfer only
- Pipes 6-7: interrupt transfer only
- No isochronous support
Previously, all non-control endpoints were unconditionally advertised
as supporting bulk, interrupt, and isochronous transfers, which is
incorrect for this variant
Therefore shim-code udc_renesas_ra.c needed changes to properly configure
the pipe-configuration for this 5-pipe usbfs variant.
Signed-off-by: Victor Hogeweij <hogeweyv@gmail.com>
Crypto driver nested in the Infineon MXCRYPTO mfd driver.
The driver supports select AES and Hash operations.
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: Laura Carlesso <laura.carlesso@infineon.com>
MXCRYPTO mfd driver intended to supported a crypto driver and
a trng (entropy) driver.
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: Laura Carlesso <laura.carlesso@infineon.com>
The need_setup member of struct i2c_dw_dev_config only exists when
CONFIG_I2C_ALLOW_NO_STOP_TRANSACTIONS is enabled, and every other
access to it in the driver is wrapped in a matching #if. The write
added in i2c_dw_transfer() to require a re-setup after a failed or
aborted transaction was left unguarded, so the driver fails to build
whenever that option is off:
drivers/i2c/i2c_dw.c:1032:19: error: 'struct i2c_dw_dev_config'
has no member named 'need_setup'
Wrap the write in the same #if used by the rest of the driver.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
uart_gecko_irq_tx_enable() enables both the TXBL and TXC interrupts,
but nothing in the standard interrupt-driven flow clears the TXC
flag: it is write-1-to-clear and only uart_gecko_irq_tx_complete()
clears it, which typical interrupt handlers (servicing
uart_irq_tx_ready() and uart_irq_rx_ready()) never call. Once a
transmission completes, TXC stays pending and the UART interrupt
re-enters continuously whenever TX is enabled, spinning at hardware
interrupt priority between TXBL servicing opportunities.
This is the same defect as in the silabs usart driver fixed by the
previous commit, where it was measured on hardware (82017 ISR entries
for 1811 TX-ready services on xg24_rb4186c). The gecko driver shares
the exact structure: TXC enabled as an interrupt source, no stale
flag clearing in irq_tx_enable() or irq_tx_disable(), and
irq_is_pending() not reporting TXC. This change is build-tested for
slwrb4104a but not validated on Series 0/1 hardware.
Only enable TXBL, which is sufficient to pace FIFO refills, and clear
the stale TXC flag when TX is disabled so uart_irq_tx_complete()
cannot report a completion from a previous transmission.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
uart_silabs_irq_tx_enable() enables both the TXBL and TXC interrupts,
but nothing in the standard interrupt-driven flow clears the TXC flag:
it is write-1-to-clear and only uart_silabs_irq_tx_complete() clears
it, which typical interrupt handlers (servicing uart_irq_tx_ready()
and uart_irq_rx_ready(), as the console, shell and Bluetooth monitor
do) never call. Once the first frame completes, TXC stays pending and
the UART interrupt re-enters continuously for the whole duration of a
transmission, spinning at hardware interrupt priority between TXBL
servicing opportunities (one byte time apart at the configured baud
rate). The driver's own irq_is_pending() does not include TXC either,
so the documented "while (uart_irq_is_pending())" handler idiom cannot
observe the interrupt cause it is being invoked for.
This is distinct from and not addressed by commit 3a6406439c
("drivers: serial: silabs: Only clear processed flags"), which fixed
flag clearing inside irq_tx_complete() itself but did not change TXC
being enabled as an interrupt source that no standard handler
acknowledges.
Measured on xg24_rb4186c with an interrupt-driven TX user that
services only uart_irq_tx_ready(): 82017 ISR entries for 1811 TX-ready
services. The storm throttles every thread on the CPU to the UART
byte rate, and starves the radio hard enough to break Bluetooth link
supervision under load. With this fix the same workload shows 805139
TX-ready services in 806757 ISR entries.
Only enable TXBL, which is sufficient to pace FIFO refills, and clear
the stale TXC flag when TX is disabled so uart_irq_tx_complete()
cannot report a completion from a previous transmission. TXC remains
readable through uart_irq_tx_complete(), which uses the raw interrupt
flag rather than the enabled mask.
The eusart driver also enables TXC from irq_tx_enable(), but clears
stale TXC flags in both irq_tx_enable() and irq_tx_disable(), which
prevents the storm; this was verified on the same hardware (497
interrupts for 497 TX-ready services when transmitting 512 bytes).
The legacy gecko driver shares the vulnerable structure and is fixed
in the following commit.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
