Drop the hand-rolled tick accounting for the generic core. CMT1 keeps
free-running as the cycle source and CMT0 keeps raising the tick
interrupt. What goes away is everything between them: the announce
baseline, the cycle-to-tick division in three places, the deadline
arithmetic and the private spinlock.
This is a RELOAD backend rather than a compare one, because the compare
register belongs to a different counter than the cycle source. The core's
absolute deadlines live in CMT1's domain, which says nothing about CMT0's
CMCOR, so what CMT0 can be given is a relative delay. CMT0 exists only to
raise the interrupt, nothing reads its count, so the arming primitive
restarts it and CMCOR becomes exactly the delay the core asked for.
Two CMCOR pathologies in the old sys_clock_set_timeout() go with it. It
special-cased the maximal tick value by declining to reprogram at all,
which left whatever period was already loaded in place forever, and it
could compute a CMCOR of zero, which matches on every count. The core
neither special-cases a tick value nor programs a reload below
TIMER_CORE_ALARM_MIN_CYCLES, set here to two so CMCOR never lands on a
just-cleared CMCNT.
CMT1's software extension stays, so the core is given 32 bits rather than
the raw 16. One CMT1 period is 10.9 ms at 6 MHz and a masked delta
aliases past that, so a k_busy_wait() holding interrupts for longer would
see the cycle counter go backwards and uptime stop. That is poor practice
on the caller's part, but it has to keep working for well over a second.
Folding the wrap in on each read is what keeps the extension alive while
no ISR can run, and it makes the read stateful, hence
TIMER_CORE_COUNTER_NONATOMIC. A wrap is still only caught if something
reads within the period, which the arming bound and any busy-wait loop
both ensure. The arm range stays 16 bits, all CMT0's CMCOR holds.
Tested on qemu_rx/r5f562n8, kernel and arch suites, and build-tested on
rsk_rx130@512kb/r5f51308axfp.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This driver integrates with the Zephyr regulator API to control the
MAX20362 PMIC. Additional MAX20362-specific helper functions are
exposed to support device features that are not covered by the
generic regulator API.
Signed-off-by: Anthony Raterta <Anthony.Raterta@analog.com>
Add a driver for the VIRTIO I2C adapter device (virtio spec 1.3, section
5.16), letting a Zephyr guest drive an I2C bus exposed by a hypervisor or
a vhost-user backend.
One i2c_msg is one descriptor chain, and the whole batch is queued before
the device is notified, so a multi-message transfer costs one round trip
instead of one per message. FAIL_NEXT groups the messages the device runs
back to back; a message that ends in a stop closes its group, so a failure
takes the rest of that group with it.
Every operation is a round trip to the device, so the I2C API can only be
used from a thread. VIRTIO_I2C_F_ZERO_LENGTH_REQUEST is mandatory, so a
device that does not offer it is refused. 10-bit addressing is not
supported, and the bus speed is accepted and ignored.
Assisted-by: Claude Code:opus-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Both commands enter receive mode first and leave it afterwards, since
the RSSI only means anything while the radio is receiving.
Signed-off-by: JaeHwan Jin <jaehwan.jin@rakwireless.com>
Add lora_energy_detect(), which reports whether a channel carries energy
above a threshold. Unlike lora_cad() it reacts to any transmitter, not
only to a LoRa preamble.
No radio has a command for this, so it is built in common code on top of
lora_recv_async() and lora_rssi() rather than added as a driver
operation. Variants such as tracking the peak level can then be written
without touching any backend.
The receiver needs time to settle before the first sample is valid, so
the wait before sampling and the interval between samples are Kconfig
options. The settling time is measured per backend, so it defaults to
0.5 ms on loramac-node and the native driver and to 10 ms otherwise.
Signed-off-by: JaeHwan Jin <jaehwan.jin@rakwireless.com>
Wire lora_rssi() to the primitive each backend already exposes:
Radio.Rssi() in loramac-node, ral_get_rssi_inst() in LoRa Basics Modem
and the GET_RSSI_INST command in the native SX126x driver.
The native LR11xx driver and the RYLRxxx modem are left out. LR11xx has
the command but no hardware was on hand to test it, and RYLRxxx is an AT
command module with no equivalent.
Signed-off-by: JaeHwan Jin <jaehwan.jin@rakwireless.com>
One SX126x bus access is three steps: wait for the chip to be ready,
run the transfer, then wait for it to go idle again. The idle wait
sleeps, so a second thread can enter the sequence in the middle and
leave the handshake out of step.
No caller has hit this so far. Reading the RSSI of a receive already in
progress is the first case where the calling thread and the DIO1 work
handler are on the bus at the same time, so take a binary semaphore
around the sequence. Nothing inside the sequence re-enters it, so the
lock never needs to be recursive.
SX127x needs no equivalent: one access there is a single transfer,
which the SPI driver already serialises.
Signed-off-by: JaeHwan Jin <jaehwan.jin@rakwireless.com>
The MFD init hook calls Cy_Crypto_Core_Enable(), but the driver never
selected the MXCRYPTO PDL sources that provide it: those are only
built when the TRNG or the crypto child driver selects one of the
USE_INFINEON_MXCRYPTO_* symbols. Any build that enables MFD for
another Infineon function driver (the autanalog or HPPASS drivers,
for instance) but leaves crypto and entropy off therefore failed to
link:
undefined reference to `Cy_Crypto_Core_Enable'
This broke the kit_pse84_eval comparator, adc_stream and autanalog
tests once the board defconfigs stopped enabling crypto and entropy.
Add USE_INFINEON_MXCRYPTO_CORE for the PDL sources shared by the three
accelerators and select it from the MFD driver, so the driver builds
on its own. Enable it by default only when a child function driver is
enabled so it is no longer pulled into builds with no use for the
block.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:opus-5
When switching to CMUX mode, request the MTU that Zephyr is capable of
sending, instead of a hardcoded value.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Validate pin against the controller's port_pin_mask before entering the
API, and return -EINVAL for anything the controller does not support.
Signed-off-by: Flavio Ceolin <flavio@hubble.com>
Enable the DSI host and the scanout controller on both ESP32-P4
function EV boards, and describe the panel on the LCD adapter.
The D-PHY draws from the internal LDO channel 3, so the boards
turn that rail on at 2.5 V, without which the PLL never locks.
Panel reset is on GPIO27 and the backlight on GPIO26, the pins
both boards route to the LCD adapter.
The DPI clock divides a fixed 240 MHz source, so it is set to a
rate that divider reaches exactly.
Assisted-by: Claude:opus-4-8
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Add the ESP32-P4 MIPI DSI host, which brings up the D-PHY, sends
DCS and generic packets, and programs the DPI timings a panel
reports when it attaches.
Attaching also starts the scanout controller described under the
host, once the pixel format is known, and detaching stops it.
Assisted-by: Claude:opus-4-8
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Add the display driver for the DSI bridge, which streams a
framebuffer to the host DPI port. It owns the framebuffers,
presents a completed frame at the next frame boundary so an
update is tear-free, and reports frame events.
Reading back returns the buffer on screen, and blanking is
forwarded to the panel, which owns the backlight. The MIPI DSI
host starts and stops it, since the framebuffer size depends on
the pixel format the panel reports when it attaches.
Assisted-by: Claude:opus-4-8
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
A field fault traced to the CRSF RX_RDY path: the parser was handed a
buffer window whose base pointer read a wild address, faulting in ISR
context. The serial driver's async double-buffer accounting was audited
and found self-consistent: the RX_RDY event reports a (buf, offset, len)
window derived under lock from a single view, with offset and length
bounded by the buffer length, so the wild base pointer cannot come from
that accounting alone and the root mechanism could not be pinned in the
serial layer. This guard is containment at the buffer owner, not a fix
for a proven serial-driver defect.
The CRSF driver supplies the two RX DMA buffers, so it can validate the
event before trusting it: require the RX_RDY buffer to be one of those
two buffers and the offset/len window to stay within CRSF_RX_BUF_SIZE
before invalidating cache or parsing. Anything else is dropped so a
stale or corrupt window can never reach crsf_process_bytes.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
crsf_process_bytes runs in UART ISR context on whatever chunk the async
driver hands up, so it must survive torn and malformed frames from a
noisy link without walking off a buffer.
Sanity-check the incoming chunk on entry: reject a NULL pointer, an
empty chunk, or a chunk larger than one RX DMA buffer before
dereferencing it. Bound every store into rd_data against its size,
resetting the state machine on any violation so no protocol-invariant
slip can write out of bounds. Guard every length decrement: check
payload_remaining before decrementing in the TYPE, IGNORE, and DATA
states, treating zero-when-a-byte-is-still-expected as a framing error
that reframes to SYNC. Route all resets through a single
crsf_reset_parser helper to keep the hot ISR loop cheap.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
The RM3100 streaming read acquires five bus SQEs one at a time and, on a
short pool, calls rtio_sqe_drop_all() to clean up. rtio_sqe_drop_all frees
every SQE queued on the shared bus RTIO context, including SQEs still in
flight from another read chain, returning an in-use SQE to the pool. A
later allocation then hands out that SQE with a corrupted back-pointer and
the completion path dereferences it, hard-faulting in the RTIO executor
(observed on I2C RM3100 hardware as a bus fault in the sensor work queue
after "Failed to acquire RTIO SQEs").
Acquire the five SQEs of a chain as one array with rtio_sqe_acquire_array,
which pushes nothing until all five are held and rolls its own back on
shortage, so a partial acquire can no longer orphan or double-free an SQE.
The incomplete NULL check that omitted the two status SQEs is retired with
it. Double the bus context pool from 8 to 16 so a five-SQE chain does not
run the pool short under streaming load.
The one-shot read path still acquires its SQEs individually and returns
early on shortage without preparing them. That is a lower-pressure path
outside the streaming scope of this change and is left to a follow-up.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
In a streaming read-config the channels union member holds the trigger
array, so the encoded channel mask was computed from reinterpreted
trigger data and came out 0, making every streamed frame fail decode
with -ENODATA. A data-ready event always carries all three axes, so
encode a fixed MAGN_XYZ channel spec in the stream path.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
The bus read helpers unconditionally OR the SPI read-address flag into
the register address. On I2C the register address must be sent raw:
with the flag set every read addresses a nonexistent register and
returns zeros, so the sensor appears dead on I2C buses.
Gate the flag on the RTIO bus type so I2C transfers send the plain
register address while SPI behavior is unchanged.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
The event handler drops an interrupt whenever a stream is already in
progress or no submission is armed. During a stall these fire on every
data-ready edge, and one warning per event floods the log backend and
can starve the threads that would clear the stall. Count the dropped
events and emit at most one summary per second so the fault stays
visible without flooding.
A summary that carries the suppressed count is used rather than a plain
rate-limited log (LOG_WRN_RATELIMIT) so the operator sees how many edges
were dropped in the interval, not just that dropping occurred. The
counters and the report deadline live in per-instance driver data so a
two-IMU system attributes and rate-limits each sensor independently
instead of aggregating them into one shared total.
An alternative that removes the busy-path re-entries outright, disabling
the DRDY interrupt on entry to ICM45686_STREAM_BUSY and re-arming it
from icm45686_stream_submit, was considered and set aside: it changes
the pulse-mode interrupt timing for every user of this driver, so it is
left for a separate change validated on hardware.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
icm45686_event_handler loaded read_cfg from
data->stream.iodev_sqe->sqe.iodev->data at function entry, before the
guard that checks whether iodev_sqe is NULL. A data-ready edge that
arrives before a streaming submission is armed therefore dereferenced a
NULL pointer. Handle the no-submission case in its own guard that
ignores the spurious interrupt and returns, keep the cancelled
submission path separate, and defer the read_cfg load until after both
checks.
Add a driver test that invokes the handler with no submission armed and
confirms the interrupt is ignored. The test compiles the stream
translation unit directly with stubbed bus helpers so the guard can be
exercised without a full bus and device instance, and enables
CONFIG_ICM45686_STREAM through Kconfig so the driver data layout matches
the streaming build.
Signed-off-by: James Goppert <james.goppert@gmail.com>
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
icm45686_stream_init passed an uninitialized int_config to
icm456xx_set_config_int, whose purpose there is to disable every INT1
source. The unwritten fields are stack garbage, so the call could
instead enable arbitrary INT1 sources and assert a data-ready edge
before the RTIO stream is armed. The APEX (icm45686.c) and trigger
(icm45686_trigger.c) init paths already memset it to INV_IMU_DISABLE
first, so do the same on the streaming path.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
The delayable phy_work item was initialized only after the link
interrupt had already been enabled and armed. On hardware that
asserts the PHY interrupt GPIO immediately at configuration time,
the ISR (phy_tja1103_handle_irq) could run and call
k_work_reschedule() on phy_work before k_work_init_delayable()
had ever executed, rescheduling a work item with no valid handler
and corrupting the workqueue state (fault or undefined behavior on
early link-up, observed on TJA1103-based 100BASE-T1 hardware).
Initialize data->timeout and the delayable work at the top of
phy_tja1103_cfg_irq_poll(), before the interrupt is enabled, so the
handler is always valid when the ISR fires. Replace the direct
phy_work_handler() call at the end with a K_NO_WAIT reschedule so
the first poll still runs from the workqueue context rather than
inline.
Signed-off-by: Benjamin Perseghetti <bperseghetti@rudislabs.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending(), dropping the dependency on
cmsis_core.h where nothing else needed it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending(), dropping the dependency on
cmsis_core.h where nothing else needed it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ() calls with
k_irq_set_pending()/k_irq_clear_pending(), dropping the dependency on
cmsis_core.h where nothing else needed it. These platforms are
plain-NVIC Cortex-M, so the pending-state capabilities are always
available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ()/
NVIC_EnableIRQ() calls with the portable k_irq_set_pending()/
k_irq_clear_pending()/irq_enable() equivalents. The Smartbond DA1469x
is a plain-NVIC Cortex-M33, so the pending-state capabilities are
always available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ()/
NVIC_EnableIRQ() calls with the portable k_irq_set_pending()/
k_irq_clear_pending()/irq_enable() equivalents. The Smartbond DA1469x
is a plain-NVIC Cortex-M33, so the pending-state capabilities are
always available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ()/
NVIC_EnableIRQ() calls with the portable k_irq_set_pending()/
k_irq_clear_pending()/irq_enable() equivalents. The Smartbond DA1469x
is a plain-NVIC Cortex-M33, so the pending-state capabilities are
always available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ()/
NVIC_EnableIRQ() calls with the portable k_irq_set_pending()/
k_irq_clear_pending()/irq_enable() equivalents. The Smartbond DA1469x
is a plain-NVIC Cortex-M33, so the pending-state capabilities are
always available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ()/
NVIC_EnableIRQ() calls with the portable k_irq_set_pending()/
k_irq_clear_pending()/irq_enable() equivalents. The Smartbond DA1469x
is a plain-NVIC Cortex-M33, so the pending-state capabilities are
always available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ()/
NVIC_EnableIRQ() calls with the portable k_irq_set_pending()/
k_irq_clear_pending()/irq_enable() equivalents. The Smartbond DA1469x
is a plain-NVIC Cortex-M33, so the pending-state capabilities are
always available where this code builds.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ() calls with
k_irq_set_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ() calls with
k_irq_set_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ() calls with
k_irq_set_pending()/k_irq_clear_pending().
This also deletes the driver's private counter_stm32_set_pending()
helper, which hand-dispatched between the ARM GIC and the NVIC --
exactly what the portable API now does -- along with its conditional
gic.h include.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ() calls with
k_irq_set_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC_SetPendingIRQ()/NVIC_ClearPendingIRQ() calls with
k_irq_set_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The late-alarm comment still referred to NVIC_SetPendingIRQ() after
the code moved to k_irq_set_pending(); make it match.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending(), dropping the dependency on
cmsis_core.h where nothing else needed it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
This also deletes the driver's private GIC-or-NVIC dispatch helper,
which is exactly what the portable API now provides.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
This also deletes the driver's private GIC-or-NVIC dispatch helpers,
which are exactly what the portable API now provides.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Replace direct NVIC pending-state calls with k_irq_set_pending()/
k_irq_is_pending()/k_irq_clear_pending().
Assisted-by: Claude:claude-opus-5
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
