Resuming the device involves hardware accesses including register
writes, so we need to acquire the semaphore lock first to avoid
interference with other cores also using the RNG.
Signed-off-by: Sarah Renkhoff <sarah.renkhoff@gmail.com>
Wire up the i2c_api.transfer_cb endpoint so I2C transfers routed through
an I3C controller can use the asynchronous completion callback when
CONFIG_I2C_CALLBACK is enabled. The async path mirrors the existing
CONFIG_I3C_CALLBACK implementation and shares the same async_sem,
timeout timer, cb/userdata state, serialized through async_sem.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Implement i3c_transfer_cb and i3c_do_ccc_cb in the Cadence I3C
controller driver. The existing transfer functions are refactored
with an async flag that skips waiting for completion and instead
starts a kernel timer for timeout handling. A semaphore serializes
async operations, and the user callback is invoked from the
transfer completion ISR or the timeout handler.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
Add an asynchronous callback API for I3C, similar to the existing
i2c_transfer_cb interface. This introduces i3c_transfer_cb and
i3c_do_ccc_cb, which start a transfer and return immediately,
invoking a user-provided callback upon completion or timeout.
A new CONFIG_I3C_CALLBACK Kconfig option gates the feature. The
driver API struct is extended with do_ccc_cb and i3c_xfers_cb
function pointers under CONFIG_I3C_CALLBACK.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
When writing to the SSD1322 L4 display, the driver correctly checks
that the X coordinate origin is aligned to the hardware's pixel
packing requirements.
However, it failed to verify that the width of the write buffer
was also aligned. This caused the driver to accept unaligned writes,
resulting in partial byte processing and display corruption when
CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH was not properly configured.
Add a missing desc->width alignment check to prevent invalid writes.
Fixes: #106558
Signed-off-by: Archit Anant <architanant5@gmail.com>
When writing to the SSD1363 L4 display, the driver correctly checks
that the X coordinate origin is aligned to the hardware's pixel
packing requirements.
However, it failed to verify that the width of the write buffer
was also aligned. This caused the driver to accept unaligned writes,
resulting in partial byte processing and display corruption when
CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH was not properly configured.
Add a missing desc->width alignment check (multiple of 4) to prevent
invalid writes.
Fixes: #106558
Signed-off-by: Archit Anant <architanant5@gmail.com>
When writing to the SSD1327 L4 display, the driver correctly checks
that the X coordinate origin is aligned to the hardware's pixel
packing requirements.
However, it failed to verify that the width of the write buffer
was also aligned. This caused the driver to accept unaligned writes,
resulting in partial byte processing and display corruption when
CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH was not properly configured.
Add a missing desc->width alignment check to prevent invalid writes.
Fixes: #106558
Signed-off-by: Archit Anant <architanant5@gmail.com>
When writing to the SSD1320 L4 display, the driver correctly checks
that the X coordinate origin is aligned to the hardware's pixel
packing requirements.
However, it failed to verify that the width of the write buffer
was also aligned. This caused the driver to accept unaligned writes,
resulting in partial byte processing and display corruption when
CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH was not properly configured.
Add a missing desc->width alignment check to prevent invalid writes.
Fixes: #106558
Signed-off-by: Archit Anant <architanant5@gmail.com>
When writing to the SH1122 L4 display, the driver correctly checks
that the X coordinate origin is aligned to the hardware's pixel
packing requirements.
However, it failed to verify that the width of the write buffer
was also aligned. This caused the driver to accept unaligned writes,
resulting in partial byte processing and display corruption when
CONFIG_LV_Z_AREA_X_ALIGNMENT_WIDTH was not properly configured.
Add a missing desc->width alignment check to prevent invalid writes.
Fixes: #106558
Signed-off-by: Archit Anant <architanant5@gmail.com>
While other lines of the STM32 family have their flash controllers with
option bytes driver support, the STM32F1 line was missing it.
(Which might have something to do with the rather complex handling that
it needs to program them.) This patch adds support for modifying the
option bytes as they are represented in FLASH/OBR, which involves erasing
all option bytes (including the write protection bytes), then writing
back the new values for each (restoring the write protection to its
previous value).
Signed-off-by: Benedek Kupper <kupper.benedek@gmail.com>
Add support for Silergy SY6974B 3A single-cell Li-Ion switching battery
charger with I2C control, USB BC1.2 detection, OTG boost and power-path
management.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:opus-4.7
Fix below warnings on 64bit platforms:
drivers/usb/udc/udc_dwc2.c: In function 'dwc2_tx_fifo_write':
rivers/usb/udc/udc_dwc2.c:454:29: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
454 | sys_write32((uint32_t)buf->data,
| ^
drivers/usb/udc/udc_dwc2.c: In function 'dwc2_prep_rx':
drivers/usb/udc/udc_dwc2.c:651:29: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
651 | sys_write32((uint32_t)data,
| ^
drivers/usb/udc/udc_dwc2.c: In function 'dwc2_read_fifo_setup':
drivers/usb/udc/udc_dwc2.c:2324:25: warning: format '%d' expects argument
of type 'int', but argument 2 has type 'size_t' {aka 'long unsigned int'}
2324 | LOG_ERR("%d bytes SETUP", size);
| ^~~~~~~~~~~~~~~~ ~~~~
| |
| size_t {aka long unsigned int}
include/zephyr/logging/log_core.h:336:50: note: in definition of macro
'Z_LOG2'
336 | z_log_printf_arg_checker(__VA_ARGS__);
| ^~~~~~~~~~~
include/zephyr/logging/log.h:62:22: note: in expansion of macro 'Z_LOG'
62 | #define LOG_ERR(...) Z_LOG(LOG_LEVEL_ERR, __VA_ARGS__)
| ^~~~~
drivers/usb/udc/udc_dwc2.c:2324:17: note: in expansion of macro 'LOG_ERR'
2324 | LOG_ERR("%d bytes SETUP", size);
| ^~~~~~~
drivers/usb/udc/udc_dwc2.c:2324:27: note: format string is defined here
2324 | LOG_ERR("%d bytes SETUP", size);
| ~^
| |
| int
| %ld
drivers/usb/udc/udc_dwc2.c: In function 'dwc2_handle_oepint':
drivers/usb/udc/udc_dwc2.c:2615:51: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
2615 | sys_cache_data_invd_range((void *)(addr - 8), 8);
| ^
drivers/usb/udc/udc_dwc2.c:2616:45: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
2616 | memcpy(priv->setup, (void *)(addr - 8), sizeof(priv->setup));
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
When switching ETHA operating modes, the transition may fail to
complete if the PHY-derived clock is unexpectedly stopped, leaving
RMAC in an indeterminate state.
If the requested mode is not reached within the timeout, enable
RMAC emergency clock recovery (MIOC0) to flush internal RMAC state
and temporarily switch to a free‑running clock. Wait for the ETHA
mode transition to complete, then restore normal PHY clocking.
This improves robustness of RMAC/ETHA mode transitions without
requiring a full device reset.
Signed-off-by: Khai Cao <khai.cao.xk@renesas.com>
Align all sensor drivers that are using stmemsc (STdC) HAL i/f
to new APIs of stmemsc v2.13.2
Requires https://github.com/zephyrproject-rtos/hal_st/pull/35
Signed-off-by: Armando Visconti <armando.visconti@st.com>
SF32LB DMA cleared its software busy bit on half-complete.
The QSPI NOR write path polled that bit while holding the flash lock.
Clear the DMA status bit only on completion or error.
Derive busy from the active state plus pending_length.
Poll pending_length until the flash DMA transfer reaches zero.
Signed-off-by: Haoran Jiang <halfsweet@halfsweet.cn>
The SF32LB MPI QSPI NOR erase path issued WREN only once before
entering the erase loop. On SPI NOR devices the write-enable latch
is typically cleared after each erase command, so a multi-block erase
can fail after the first block.
Move WREN into the loop and issue it while holding the driver lock,
immediately before the selected erase command. This matches the write
path and aligns the driver with Zephyr's generic SPI NOR erase flow.
Signed-off-by: Haoran Jiang <halfsweet@halfsweet.cn>
ad405x_reg_update_bits() performs a raw read-modify-write without
shifting the value into the field position. The sample rate field
in TIMER_CONFIG occupies bits [7:4] (AD405X_FS_BURST_AUTO_MSK =
GENMASK(7, 4)), but ad405x_set_sample_rate() passes the raw enum
value (0-15) without shifting it.
This causes the rate value to be written into bits [3:0] instead
of bits [7:4], corrupting unrelated fields and setting the wrong
sample rate.
Shift the value by 4 to place it into the correct bit position,
consistent with how other callers handle non-zero-based fields
(e.g., ad405x_set_gp_mode() manually shifts for GP1_MODE_MSK).
Fixes: 4a9d1473d3 ("drivers: adc: ad405x: Add AD405X driver")
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Instead of switching the DLCI channel used for AT commands from DLCI1 to
DLCI2 halfway through the setup process, always use DLCI1. For PPP, use
the clean DLCI2 channel. The only "command" sent on the DLCI2 channel
before handing over to the PPP module is the dial script.
Signed-off-by: Jordan Yates <jordan@embeint.com>
This reverts commit 8d45e18d23.
With the intent to keep the AT command channel on DLCI1 and use DLCI2
exclusively for PPP, the concern about buffered messages when the
channel switches is no longer relevent.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Calculate the future time correctly to avoid negative value for "value_ms".
Register the pm_policy_event when HAL_RADIO_TIMER_SetRadioTimerValue
returns success.
Signed-off-by: Ali Hozhabri <ali.hozhabri@st.com>
Handle repetition and adaptive health test errors for STM32WB09 properly.
Resetting Health error flags is not enough. See also RM0505 §14.7.11
Signed-off-by: Ali Hozhabri <ali.hozhabri@st.com>
Avoid entering low power mode while waiting for an event to be
generated by TRNG interrupt when CONFIG_PM_S2RAM is set.
Signed-off-by: Ali Hozhabri <ali.hozhabri@st.com>
Add support for the no-3-3-v and no-3-0-v devicetree properties in the
IMX USDHC driver. When both are set, the driver overrides the host
capability flags to disable 3.3V and 3.0V support, and sets the USDHC
VSELECT bit at init time to configure the data line sampling threshold
for 1.8V I/O without triggering the SD voltage switch protocol.
Update the reset function to respect the voltage configuration: when
both no-3-3-v and no-3-0-v are set, the reset path now restores 1.8V
signaling instead of unconditionally switching to 3.3V, ensuring correct
behavior after card re-initialization on fixed 1.8V I/O boards.
This is required for boards like the MIMXRT700-EVK where the USDHC1
I/O voltage domain (VDDIO_0) is fixed at 1.8V.
Signed-off-by: Lucien Zhao <lucien.zhao@nxp.com>
Initialize the 32-bit DR temporary at declaration before copying a
partial tail chunk in qspi_nor_write_fifo(). Without this, 1-3 byte
writes can leave the upper bytes unchanged and push stale bits into
MPI_DR.
Signed-off-by: Haoran Jiang <halfsweet@halfsweet.cn>
In adxl362_set_interrupt_mode(), the LINKLOOP field is first cleared
from the register value, but then the original uncleared register
value is OR'd back in on the next line, restoring the old LINKLOOP
bits. This makes it impossible to change the interrupt mode from its
current value.
Remove the erroneous OR of old_act_inact_reg so the cleared field is
properly set to the new mode value.
Fixes: 11295c190b ("drivers: sensor: Add ADXL362 interrupt handling")
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Add support for multiple plane devices to the SPI NAND driver.
This includes adding a new plane-bytes property to the device
tree bindings, which indicates the size of each plane in the
flash device. For devices with a single plane, this should be
set to the same value as size-bytes.
Some devices require the plane address as part of read and/or
program commands. For these devices, the new has-read-plane-select
and has-program-plane-select properties can be set to indicate
that the driver should include the plane address in read and
program commands.
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
i3c_bus_rstdaa_all() sends the RSTDAA broadcast and clears every
attached descriptor's dynamic_addr, but does not return those
addresses to the address-slot pool. Subsequent calls to
i3c_addr_slots_next_free_find() therefore skip the freed DAs and
the bus monotonically exhausts the valid dynamic-address range
across successive RSTDAA + DAA cycles.
Free each target's DA in the address-slot bookkeeping in the same
loop that clears dynamic_addr, so RSTDAA is fully reversible at
the software level.
This fixes sustained RSTDAA+DAA test cycles across all I3C
controller drivers (cadence, dw, mcux, max32, stm32, npcx,
renesas, it51xxx). Previously, after ~10-20 RSTDAA cycles the
bus would run out of assignable dynamic addresses.
Signed-off-by: Sudarshan Iyengar <sudarshan.iyengar@alifsemi.com>
Assisted-by: Claude:claude-opus-4.7
The DesignWare I3C controller driver maintained several pieces of
per-target state that went out of sync with hardware whenever DAA ran
more than once on the same bus (e.g., boot DAA, RSTDAA + DAA, or a
second explicit i3c_do_daa() call).This desynchronization between
software state and hardware resulted in persistent -ENXIO errors
on all transfers after bus re-enumeration.
Root cause (shared by all three fixes below):
The DW controller's ENTDAA implementation treats DAT slots as a free
pool. It fills empty slots starting at COMMAND_PORT_DEV_INDEX in
arbitration order (lowest PID wins first). This order is unrelated to
the slot chosen by dw_i3c_attach_device() at subsystem init. The driver
previously assumed the attach-time binding was stable across DAA
cycles and never re-read hardware state; any target that participated
in ENTDAA (i.e., had no "assigned-address" in DT, or lost its DA via
RSTDAA) ended up with desc->controller_priv pointing to one DAT slot
while hardware had placed the target in another.
Three related issues are fixed together:
1. add_slave_from_daa() did not refresh BCR/DCR on re-DAA. The I3C
spec allows a target to publish different BCR/DCR after a reset,
and after RSTDAA the cached values may no longer reflect the
target's current capabilities. Always re-read from the Device
Characteristic Table when a new DA is assigned.
2. add_slave_from_daa() did not detect the priv->id != pos case
described above. When it occurs (the common case for any DT
target without "assigned-address"), rebind controller_priv to
the DAT slot hardware chose and return the old slot to the free
pool. Without this, subsequent transfers write the command DAT
index of an empty slot and NACK with -ENXIO.
3. dw_i3c_device_find() only searched the static dev_list built
from DT. Targets allocated dynamically for non-DT devices on the
bus were invisible to PID lookups, so add_slave_from_daa() kept
allocating fresh descriptors on every DAA cycle and eventually
exhausted the descriptor pool. Fall back to scanning the
attached-device runtime list by PID when the static lookup
misses.
Signed-off-by: Sudarshan Iyengar <sudarshan.iyengar@alifsemi.com>
Assisted-by: Claude:claude-opus-4.7
Implement .recover_bus for both the i3c and i2c_api entries in the
DesignWare I3C driver so that i3c_recover_bus() and the i3c shell
can actually recover a stuck bus. Previously the callback was not
wired up and calls returned -ENOSYS.
The implementation deliberately avoids RESET_CTRL_SOFT and the
RESET_CTRL_ALL superset, because those clear the Device Address
Table (DAT) and Device Characteristic Table (DCT), destroying the
driver-to-hardware mapping of attached targets. Instead the
recovery path:
- drains any pending IBIs that could block a resume,
- flushes the command, response, RX, TX, and IBI queues,
- asserts DEV_CTRL_RESUME to clear a halt caused by a prior
transfer error.
This is the same FIFO flush + RESUME sequence already used by the
driver's per-transfer error path, so the safety properties are
well understood. The operation is mutex-guarded to avoid racing
with in-flight transfers.
Signed-off-by: Sudarshan Iyengar <sudarshan.iyengar@alifsemi.com>
Assisted-by: Claude:claude-opus-4.7
Since bt_hci_evt_hdr is a variable sized struct, it shall be
located at the end of the struct.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
For devices that does not have interrupt pin, default to polling mode
instead.
Polling period can be configured through
CONFIG_ETH_W5500_POLL_PERIOD.
Signed-off-by: Aiman Mazlan <mohammad.aiman@stratusauto.com>
`hazard3_irq_init` enables `MSTATUS_IEN` too early,
which allows ISRs, specifically machine timer ISR,
to be fired before `_kernel.cpus[0].irq_stack` is
initialized in `prepare_multithreading()` /
`z_init_cpu()`.
This can result in interrupt being handled with
uninitialized IRQ stack, causing system to crash.
Signed-off-by: Andy Lin <andylinpersonal@gmail.com>
Use the scl_od_min.low_ns and scl_od_min.high_ns fields from
i3c_config_controller to configure Open Drain SCL timing instead
of hardcoding. The OD low period is programmed via PRESCL_CTRL1.od_low
and the OD high period is honored by adjusting PRESCL_CTRL0.i3c if
the base period's T/2 is insufficient.
- Load od-thigh-min-ns and od-tlow-min-ns from devicetree in the
instantiation macro
- Copy scl_od_min from incoming config in cdns_i3c_configure
- Adjust I3C prescaler upward if needed to meet high_ns minimum,
warning that push-pull speed will also be reduced
- Use scl_od_min.low_ns for OD low calculation, falling back to
I3C_OD_TLOW_MIN_NS (200ns) when unset
- Remove duplicate I3C_BUS_TLOW_OD_MIN_NS in favor of
I3C_OD_TLOW_MIN_NS from i3c.h
- Replace magic 1000000000 constants with NSEC_PER_SEC
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
commit 9b2593b8c5 has changed the internal
ili9xxx driver color config from setting BGR mode (Blue-Red channels
swap, not pixel format byte-swap) by default, to conditioning it on the
use of PIXEL_FORMAT_BGR_565 (ILI9XXX_PIXEL_FORMAT_BGR565 in devicetree),
but without updating all boards/shields to use
ILI9XXX_PIXEL_FORMAT_BGR565 to preserve their old config.
Then commit 69e353904c replaced
ILI9XXX_PIXEL_FORMAT_BGR565 to PANEL_PIXEL_FORMAT_BGR565.
Later, commit b13d9a0510 renamed
PANEL_PIXEL_FORMAT_BGR565 to PANEL_PIXEL_FORMAT_RGB565X, and defined it
as "Byte swapped version of the PIXEL_FORMAT_RGB_565 format", which is
different from how it was interpreted by ili9xxx devices (B/R channel
swapped format).
The fix for this mess is:
- separate BGR mode (B/R channel swap) setting for ili9xxx from pixel
format,
- restore the initial driver config that sets BGR mode by default, in
order to not break in-tree and out-of-tree panels that relied on that
behavior,
- introduce a DT property that allows disabling BGR mode.
A bonus enhancement is to set BGR mode in ili9xxx driver outside
set_orientation() function, since they are unrelated.
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/105521
Signed-off-by: Abderrahmane JARMOUNI <git@jarmouni.me>
If DT has IRQ defined, the board supports NMI mode, if reset-capable
property is set then the board can support reset as well. Based
on these DT properties and the flags passed by the application,
NMI mode or Reset mode can be set.
Signed-off-by: Sunil Hegde <s-hegde3@ti.com>
CONFIG_NRF_RRAM_WRITE_BUFFER_SIZE sets how many line buffers
should be used for the driver. When ther is no need to synchronize
the buffering default value should be maximal
(optimized write performance).
Whe ther is need for synchronize - value should be minimal
buffering - x1 (optimized radio firmware execution).
By mistake the default values were mixed eatch other.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Enable STM32 backup domain access on H7RS series when accessing some
RTC alarm configuration registers that otherwise would be read as 0.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
