icp201xx_trigger_set() returned -1 without releasing the driver mutex
when called with a NULL handler, deadlocking every other driver entry
point. Unregistering now clears the requested trigger's handler,
re-arms the interrupt if another trigger is still registered, unlocks
and returns 0.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
Add a bus emulator for the BMM350 so the driver can be exercised on
native_sim without hardware. It models the register file, the two dummy
bytes returned ahead of every I2C read, the soft-reset and OTP-read
handshake, and the PMU magnetic-reset / forced-mode status sequence, and
implements the emul_sensor backend (set_channel / get_sample_range) for
the magnetometer and die-temperature channels.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Report the on-die temperature via SENSOR_CHAN_DIE_TEMP. The classic API
returns it from channel_get() as a sensor_value, and the RTIO decoder
path gains a matching channel: encode tags the frame with a temperature
bit (widening the encoded channel mask to four bits), get_size_info and
decode emit it as a q31 sample, and streamed data-ready frames now carry
temperature alongside the magnetic axes. The value is reported at 0.01
degC resolution.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
The temperature was converted and compensated at 1 degC resolution, which
also truncated the 25.49 degC offset to 25 and fed only whole-degree
temperature into the magnetic TCO/TCS compensation. Carry the temperature
in centi-degC (0.01 degC) instead: apply the full 25.49 degC offset and
fold the extra factor of 100 into the TCO/TCS stages so the magnetic
compensation uses the full-resolution temperature, matching the Bosch
SensorAPI reference. The stored temperature is now in centi-degC.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
A failed pad drive-strength write in bmm350_init_chip() returned directly
instead of going through the err_poweroff path, leaving the device in an
indeterminate power state unlike every other init failure. Use the common
error path so the part is returned to suspend mode.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
set_powermode() issued the PMU command write and then slept and returned
without inspecting the write result, and bmm350_init_chip() ignored the
return value of the soft-reset command write entirely. Propagate a failed
PMU write instead of sleeping on it, and abort init (returning the part
to suspend) if the soft-reset write fails.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
bmm350_trigger_set() always wrote the full interrupt configuration,
including the data-ready enable, even when called with a NULL handler.
The Zephyr trigger API uses a NULL handler to request "disable", so
there was previously no way to turn the trigger off. Clear the
data-ready and interrupt-output enables when the handler is NULL.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
bmm350_decoder_compensate_raw_data() performed the fixed-point
compensation in int32. The cross-axis stage multiplies the per-axis
value by BMM350_MAG_COMP_COEFF_SCALING (1000) twice, which overflows
int32 once the field exceeds roughly 2 mT (reachable during self-test
excitation or saturation), corrupting the result. Use int64
intermediates for the working values and cast back to int32 only for
the final stored readings.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
bmm350_submit_one_shot() and the streaming event handler acquired the
completion-callback RTIO SQE with rtio_sqe_acquire() but used it
without checking for NULL. If the SQE pool is exhausted the acquire
returns NULL and rtio_sqe_prep_callback_no_cqe() then dereferences it.
Check the result, drop any partially-prepared SQEs and fail the
submission with -ENOMEM, matching how the preceding read SQE is already
handled.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Add bmm350_self_test() to the driver's public header, following the
Bosch BMM350 SensorAPI self-test sequence: re-initialise the TMR sensor
(suspend, flux-guide reset, fast bit reset, fast-forced mode) with
per-step PMU command status verification, then measure the response to
a positive and negative excitation on the X and Y axes.
The excited-axis response is read uncompensated and converted to
micro-Tesla using the default sensitivity coefficients, matching the
SensorAPI read_out_raw_data(); OTP compensation is intentionally not
applied since the test evaluates the differential response. Results
(per-axis responses and deltas) are reported through a
bmm350_self_test_result struct, and the prior power mode is restored on
return. Judging the deltas against the datasheet self-test limit is
left to the caller.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
The BMM350 driver only supported I2C. Extend the existing RTIO bus
abstraction to also drive the sensor over I3C, following the same
multi-bus pattern used by the bmp581 driver.
A new BMM350_BUS_TYPE_I3C bus type is selected per devicetree instance
based on the bus the node sits on. The RTIO register read/write helpers
set the I3C stop/restart iodev flags, and bus readiness is checked via
the I3C controller device. Register access, triggering and one-shot/
streaming all flow through the existing bus_io vtable unchanged.
Add a bosch,bmm350-i3c.yaml binding that reuses the common properties,
make the I2C/I3C Kconfig selects conditional on the instance bus, and
add an I3C node to the sensor build_all test.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Add support for the Texas Instruments ADC124S021, a 4-channel
12-bit SPI ADC.
The driver implements the Zephyr ADC API and supports single-ended
reads on channels 0 through 3. Unsupported ADC API features such as
programmable gain, differential mode, oversampling, calibration, and
selectable resolution return -ENOTSUP.
Signed-off-by: Manuel Sanchez Monge <manuel.sanchezm2003@gmail.com>
The FIFO temperature is a signed quantity (8-bit at 2.07 LSB/degC in
standard packets, 16-bit at 132.48 LSB/degC in hires packets, both
offset at 25 degC), but the decoder read the bytes as unsigned, so any
temperature below 25 degC decoded as a large bogus positive value and
could trip the whole-degrees range assert. Cast to the signed width
before converting.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The sensor streams sample registers MSB-first, so assembling the value
as (MSB << 8) | LSB already yields a CPU-order value. Wrapping it in
sys_le16_to_cpu() byte-swapped every sample on big-endian targets; use
sys_get_be16() instead.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The streaming header unconditionally reported fifo_count as the FIFO
watermark, even on the flush paths (SENSOR_STREAM_DATA_NOP/DROP or
FIFO_FULL trigger) where only a header-sized buffer is allocated and
no FIFO payload is read, causing the decoder to walk past the end of
the buffer. Set fifo_count to 0 unless the watermark trigger requested
the data to be included, matching the read performed in the FIFO event
handler.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The one-shot decoder read edata->readings directly, ignoring the
axis_align remap that icm4268x_encode stores in the header and that
both the FIFO decoder and the sync channel_get path apply. Index and
sign the accel/gyro readings through header->axis_align so async
one-shot reads match the other data paths.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
icm4268x_safely_configure() overwrote the primary configure error
with the rollback result, so a failed reconfigure followed by a
successful rollback returned 0 to callers such as attr_set even
though the requested configuration was never applied. Keep the
original error and only log a rollback failure.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The FIFO temperature was packed by OR-ing a FIELD_PREP'd whole part
with a fraction term computed via unsigned GENMASK64 arithmetic. For
negative temperatures both pieces are negative, so the unsigned divide
produced garbage and bitwise OR cannot perform the required signed
add. Compute the q31 value with signed 64-bit arithmetic instead.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The non-hires FIFO decode path masked with BIT(16), which can never
be set in a 16-bit sample, so negative accel/gyro values were never
sign-extended and decoded as large positive values. Use BIT(15) to
match the 20-bit hires path's BIT(19) idiom.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The simulated radio derives its centre frequency as 2407 + channel * 5,
so it only ever operates in the 2.4 GHz band and the constant is
correct.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The channel getter and both interface status handlers split the band at
channel 14, which reports a 6 GHz channel as 5 GHz. Use the shared
helper so the split is done in one place and an out of range channel
reports WIFI_FREQ_BAND_UNKNOWN.
The scan handler is left alone. It takes the band from the band field
the firmware reports for the BSS rather than deriving it, which is the
better source where it is available.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The scan handler and both interface status handlers derived the band
with an open coded "channel > 14", which reports a 6 GHz channel as
5 GHz and a channel of 0 as 2.4 GHz. Use the shared helper instead, so
an interface whose channel is not known reports
WIFI_FREQ_BAND_UNKNOWN.
The softAP status handler also assigned acs_band, a driver internal
0/1 value, straight into the band field. That happens to produce the
right answer only because the two enumerations start with the same two
values, so spell the conversion out.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The interface status handler decided the band with "channel > 11",
which places channels 12, 13 and 14 in the 5 GHz band. Those are valid
2.4 GHz channels in several regulatory domains, so a station connected
on one of them reported the wrong band. The scan handler in the same
driver used "channel > 14", so the two disagreed about the same BSS.
Use the shared helper in both places. That fixes the 12-14 range, makes
scan and status agree, and reports 6 GHz channels as 6 GHz instead of
folding them into 5 GHz. A channel the driver never filled in now reads
as WIFI_FREQ_BAND_UNKNOWN rather than 2.4 GHz.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The other Wi-Fi drivers now derive the interface status band from the
channel rather than reporting a constant. This one cannot: the part is
2.4 GHz only and the driver reports channel 0, so deriving the band
would replace a correct answer with an unknown one.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The +CWJAP: response handler set the band to WIFI_FREQ_BAND_2_4_GHZ
before parsing anything, overwriting the WIFI_FREQ_BAND_UNKNOWN that
esp_mgmt_iface_status() had deliberately set, even when the response
turned out to be unparseable and the handler returned an error.
Derive the band from the channel once the channel has been parsed. The
scan handler never set the band at all, so every scan result carried a
zero, which is WIFI_FREQ_BAND_2_4_GHZ rather than an unknown band;
derive it there too. The supported parts are 2.4 GHz only, so the band
reported for a connection does not change.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The interface status handler reported WIFI_FREQ_BAND_2_4_GHZ
unconditionally, before it had asked the co-processor anything, so a
disconnected interface and any future dual band part would both be
described as being on 2.4 GHz.
Derive the band from the channel once the channel is known, for both
the station and the access point case, and leave it as
WIFI_FREQ_BAND_UNKNOWN until then. The scan handler filled in the
channel but never the band at all, which left every scan result
looking like a 2.4 GHz one, so fill it in there as well.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The interface status band was set from the interface flags, and only
when the 2.4 GHz flag was present. Everywhere else it was left at the
value the initial memset() produced, which is WIFI_FREQ_BAND_2_4_GHZ
rather than an unknown band. An interface that is not up yet returns
early from the handler and so reported 2.4 GHz without ever looking at
the radio.
The scan handler had its own open coded version of the same conversion:
it defaulted the band to 2.4 GHz and replaced it with an unknown band
when the channel fell outside 1-14. rf_channel is a uint8_t, so the
"<= 0" half of that range test could only ever match channel 0.
Derive the band from the channel in both places, once the channel is
known, and leave it as WIFI_FREQ_BAND_UNKNOWN until then. The scan
warning is kept, now driven by the derived band, so a channel the part
cannot be on is still reported. The part is 2.4 GHz only, so the band
does not change for an interface that is actually connected.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The interface status handler reported WIFI_FREQ_BAND_2_4_GHZ
unconditionally, so on the dual band ESP32-C5 a connection on a 5 GHz
channel was shown as 2.4 GHz by "wifi status" while "wifi scan" showed
the same BSS as 5 GHz. The constant was harmless while every supported
part was 2.4 GHz only.
Derive the band from the channel once the channel is known, in both the
station and the access point case, and default to
WIFI_FREQ_BAND_UNKNOWN so that a status query that cannot determine the
channel no longer claims 2.4 GHz. The scan path already derived the
band, but only distinguished 2.4 from 5 GHz, so let it use the same
helper.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Add the option for modems to register an arbitrary configuration
structure as part of the core config. This provides a location to
store per-instance, vendor-specific information.
Signed-off-by: Jordan Yates <jordan@embeint.com>
The SRM32 CRC driver is overly pessimistic about the CRC formats the
driver supports, presumably because polynomials were previously
incorrrectly sometime passed in reflected form to the driver which
caused incorrect results in certain functions. Allow all 8-, 16, and
32-bit formats.
Signed-off-by: Zee Yudenko <zyudenko@internships.antmicro.com>
CRC polynomials can be passed in either normal or reflected form.
Reflected form is only relevant to the software CRC implementation doing
reflected calculation. We pass polynomials given to `crc*` functions
as-is to the drivers, which is incorrect if the polynomial is reflected
(which is the case when the `reflected` argument is `true`, or always in
`crc16_reflect`). Fix this by reflecting the polynomial back before
passing it to the driver. Also, remove hacks in driver code for handling
reflected polynomials. This fix makes the previously-failing
`subsys.crc` test pass on STM platforms. Also, fix uninitialised usage
of `flag_reversed` in `crc4`.
Signed-off-by: Zee Yudenko <zyudenko@internships.antmicro.com>
Rework the Renesas RZ MHU MBOX driver to align Renesas RA IPC
Mbox driver so that a single MHU unit serves both TX and RX
on one MBOX channel, and so that one driver instance can own
several channels.
Binding: rename "channel" to "unit", since it indexes the MHU
hardware unit and not the MBOX channel; replace "tx-mask" and
"rx-mask" with a single "channel-mask"; make "shared-memory"
optional.
Rename the Kconfig timeout option to
MBOX_RENESAS_RZ_MHU_BUSY_WAIT_TIMEOUT_US
Signed-off-by: Phuc Pham <phuc.pham.xr@bp.renesas.com>
Signed-off-by: Tien Nguyen <tien.nguyen.zg@renesas.com>
The numaker ethernet driver does not use
the separate ethernet controller, mdio bus, phy structure.
It does mdio inside the ethernet driver.
Until this is fixed this driver is going to be deprecated and
if not fixed in 2 releases removed.
The better way would it be to replace it with the
existing vendor independent dwc_mac driver.
Signed-off-by: Fin Maaß <f.maass@vogl-electronic.com>
Add support for accessing the 2-byte RAM of the Micro Crystal RV-3028
through the Zephyr retained memory API.
Signed-off-by: Janez Ugovsek <janez@ugovsek.info>
We don't want to be using the CONN port if possible. Reworked to use
the SSSAPI only. Initialization call now also initializes the TRNG.
Signed-off-by: Patrik Nemeth <patrik.nemeth@nxp.com>
mcux_lpuart_configure() begins by spinning unbounded on the
Transmission Complete flag before reconfiguring the peripheral. TC
only sets when the transmitter is enabled and idle, so a
uart_configure() call issued while traffic is flowing parks the
calling thread for the full duration of that traffic. Observed on an
MCXA153 driving a USB CDC-ACM to UART bridge: the host's line-coding
change (9600 -> 115200 at port open) triggered uart_configure()
against a live transfer and the configuring thread spun for 15.36 s,
the time the entire transfer took to drain at the old baud rate
(BAUD register sampled over SWD while stalled). When the loop finally
exited, the driver disabled TE/RE and reinitialized mid-frame,
deterministically corrupting the byte being received.
Bound the wait with WAIT_FOR (300 ms total, 100 us poll). On timeout,
return -EBUSY and leave the peripheral untouched so the caller can
quiesce its traffic and retry; proceeding to tear down the
transmitter and receiver at that point can only destroy in-flight
data. 300 ms covers this driver's worst-case 12-bit frame (start +
8 data + parity + 2 stop, 240 ms) at 50 baud, the slowest standard
rate, so a transmitter finishing its last frame completes within the
window; for the arbitrarily slower rates the hardware can still be
configured to, the bound is an intentional policy limit and the
resulting -EBUSY is side-effect-free and retryable.
Callers that configure an idle UART see no change: TC is already set
and WAIT_FOR returns on its first evaluation.
Signed-off-by: João Felipe <joao@binho.io>
Signed-off-by: Leonardo José Consoni <leonardo@binho.io>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
In synchronous mode, the slave SAI sub-block relies on the master
sub-block to provide the bit and frame clocks. Disabling the SAI
peripheral from the stream callback can disable the shared clock
source and prevent the synchronous slave from operating correctly.
Avoid disabling the SAI peripheral when bit clock gating is disabled,
allowing the master sub-block to continue providing clocks for the
synchronous slave.
Add a warning for synchronous slave configurations to highlight the
requirement for a matching synchronous master configuration and disabled
bit clock gating.
Signed-off-by: Mario Paja <mariopaja@hotmail.com>
Add the MCUX_FREQME_CLK clock identifier and enable the FREQME
peripheral gate (kCLOCK_Freqme) from clock_control_on() for the
IMXRT6XX, IMXRT5XX and RW6XX series, so the nxp,fmeas clock_monitor
back-end can ungate the block through the clock_control API.
The reference timebase reuses the existing MCUX_SYSTEM_CLK identifier,
which already returns the core/system clock rate on these series, so no
new rate case is required.
Signed-off-by: Felix Wang <fei.wang_3@nxp.com>
Add a clock_monitor back-end for the NXP BASIC Frequency Measurement
(fmeas) block, wrapping the MCUX SDK fsl_fmeas HAL. The block has no
interrupt line and no MIN/MAX threshold registers, so only MEASURE
(one-shot) mode is supported and WINDOW mode returns -ENOTSUP:
completion is polled from a workqueue and reported as MEASURE_DONE, or
as CLOCK_LOST when no target edges are counted. The HAL fixes the
window at 2^20 reference cycles, so window_ns is ignored.
Reference and target clocks are routed through INPUTMUX and selected at
runtime from devicetree source lists, each pairing a mux route with a
fixed rate or a clock_control provider.
Serialization is a single k_spinlock that is never held across a call
into another subsystem: configure() resolves the reference rate into
locals first and commits them in one short region, and set_source()
parks the state machine at CONFIGURING for the duration of the
re-route. start() arms the block and queues the poll inside its region
and stop() cancels inside its own, so the two cannot interleave and
both stay ISR-safe as the API requires.
Adds the nxp,fmeas binding, its NXP_FMEAS_* INPUTMUX cookie macros and
the fsl_fmeas / inputmux HAL component selection.
Signed-off-by: Felix Wang <fei.wang_3@nxp.com>
Assisted-by: Claude:claude-opus-5
The RSCANFD is capable of CAN and CAN FD communications.
It features 8 channels per controller.
Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
Build the STM32WB0 flash driver for STM32WL3x, whose flash
controller IP is compatible with STM32WB0.
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
The RP1 register field macros were only used by the pinctrl driver, so
move them into pinctrl_rp1.c and drop the public header (the RP1 GPIO
driver already defines the few fields it needs itself).
Assisted-by: Claude:opus-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
When dividing the writes into multiple block the driver doesn't sleep
after the last block write which causes a wrong throttling delay.
Fix this by removing an unnecessary check of len in the nrf_write
function.
FIXES: #118218
Signed-off-by: Riadh Ghaddab <riadh.ghaddab@nordicsemi.no>
Using k_events eliminates the drawback of the queue potentially dropping
messages and provides a reliable event notification mechanism.
With the commit c3109b9ebe
("usb: device_next: cdc_acm: rx throughput improvements"),
the CDC implementation queues as many buffers as are available.
The default UDC_KINETIS_EVENT_COUNT was set to 4, and it could already
be observed that the events are dropped. Though the number of
UDC_KINETIS_EVENT_COUNT could be increased, using k_events is the right
fix.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Align the driver design with most of the drivers in the tree and move
driver event handling from the UDC workqueue to the driver's own thread.
Driver thread handles the events under UDC internal lock and makes it
mutually exclusive with API calls. Add k_sched_lock() UDC internal lock
to avoid unnecessary context switch to the driver thread triggered by
e.g. interrupt event, while the internal lock is still held.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
z_vrfy_mux_control_disconnect() was missing the
K_SYSCALL_DRIVER_MUX_CONTROL(dev, disconnect) permission check that
every other handler in this file has. Without it, a userspace caller
could invoke mux_control_disconnect() on a device object that isn't
actually a mux controller, skipping the type/op validation the macro
provides.
Add the missing check, matching the pattern used by
z_vrfy_mux_control_set(), z_vrfy_mux_state_apply(), and
z_vrfy_mux_state_get().
Signed-off-by: Felix Wang <fei.wang_3@nxp.com>
Add support for software-managed RTS flow control to work around
hardware RTS silicon limitations on affected STM32 SoC revisions:
- Add st,sw-rts-gpios property to st,stm32-uart-base binding.
- Add UART_STM32_ABNORMAL_RTS_ERRATUM_WORKAROUND Kconfig option with
automatic GPIO selection.
- Configure USART hardware for CTS-only flow control.
- Assert RTS (active low) on rx_enable and deassert on rx_disable
or buffer exhaustion.
Fixes#36849
Signed-off-by: Priyanshu Singh <singhpriyanshu9838@gmail.com>
