Update comments, log messages, Kconfig prose, and driver-local
identifiers to use the controller/target terminology ratified by
coding guideline A.2 and already used by the Zephyr I2C API.
Identifiers mirroring the Microchip XEC datasheet
(e.g. MCHP_I2C_SMB_* register/bitfield macros, MCHP_GIRQ_* macros,
XEC_I2C_* register offset/bit macros in v2) are kept unchanged.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
The SPI burst read discarded 3 leading bytes, but the device's address
phase is only 2 bytes long, so every sample was shifted by one register.
Skip 2 bytes instead, matching the single-byte read and write paths.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Assisted-by: Claude:fable-5
Add support for the Analog Devices ADE7913 three-channel, 24-bit
sigma-delta ADC. The driver supports raw signed 24-bit synchronous
and asynchronous reads in single-channel and burst modes. Raw-value
conversion is left to the application.
Signed-off-by: Sebastian Wagner <1sebastianwagner1@gmail.com>
There are two VCO parameters the driver configures: the input range
and the operation mode (VCOL/VCOH). While the two parameters may appear
independent, they are not because the valid input ranges depend on the
selected VCO mode, which itself depends on the target vco_ck frequency.
As such, the current logic which evaluates only refx_ck to determine the
input range and "deduces" the operation mode from input range is not
correct.
While we could keep two independent routines, it seems simpler to merge
both `get_vco_input_range()` and `get_vco_output_range()` into a single
`get_vco_parameters()` routine which computes both parameters from the
refx_ck and target vcox_ck (or returns an error if the configuration is
not legal) since separate routines, if preserved, would accept the same
parameters anyways.
While at it, take advantage of the new st,vcoh-frequency-range property
to ensure the legal configuration evaluation is valid on a per-product
basis.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
The rx_thread assembles a whole HCI packet in a single static frame
buffer before handing it to the host. That buffer was hardcoded to 512
bytes. A full ACL data packet can be larger than this: the host's
receive buffer is CONFIG_BT_BUF_ACL_RX_SIZE bytes and defaults up to
1300 for Classic, and an A2DP media packet fills it. When such a packet
arrives, frame_size reaches the buffer size, the driver logs "HCI Packet
is too big for frame (512 bytes). Dropping data" and discards it. The
host then sees the truncated stream and rejects it with "Unexpected
L2CAP continuation", so no A2DP media is ever received.
Size the frame buffer from BT_BUF_RX_SIZE, which the host already uses
for its RX buffers: it includes the H4 type octet and the maximum of the
ACL, event and ISO receive-buffer sizes, so the buffer holds every
packet type get_rx() accepts, including ISO packets whose MTU can exceed
both 512 and the ACL RX size.
Verified on native_sim with a real Bluetooth dongle (HCI User Channel):
before the fix A2DP media reception failed as described above; after it,
an A2DP SBC stream from a phone is received continuously (packets both
below and above the old 512-byte limit) with no dropped-frame or L2CAP
continuation errors.
Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
RESET.LONGPRESS changed its fields' reset values which is reflected in the
defaults for their respective Devicetree properties.
RESET.CONFIG now contains a bit disabling the long-press reset behaviour
that can be overridden with user OTP. Write only the relevant mask for this
register.
Signed-off-by: Sergei Ovchinnikov <sergei.ovchinnikov@nordicsemi.no>
The new register map widens CHARGER.STATUS.STATE from three to four bits
to report the constant-current and constant-voltage phases separately.
The flags above the field move up one bit each.
Signed-off-by: Sergei Ovchinnikov <sergei.ovchinnikov@nordicsemi.no>
Setting the FICR in the driver isn't required for
nrf7120 as it is set during systeminit().
Signed-off-by: David Jewsbury <david.jewsbury@nordicsemi.no>
The channel state validation in start computed -EINVAL but fell
through and started the transfer anyway, returning success. Bail
out like the channel range check above it.
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
intc_mtk_adsp_get_enable() OR-ed the enable register with the IRQ bit,
returning true whenever any interrupt in the block was enabled. AND
the register with the requested IRQ bit instead.
Assisted-by: Claude:fable-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Enable EOT interrupts after finishing filling the TxFIFO. Otherwise, the
interrupt can be triggered before the tx_len data is decremented, which
leads to a stall.
Also explicitly disable the EOT before starting the transfer.
It solves an issue seen on WBA with the spi_loopback test.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Add helper functions for transfer size, FIFO-related interrupts, and
status flags so the SPI driver can use a common workflow across STM32
series. These new helpers are empty (or return 0) for non-H7 variants.
This allows removing a bunch of preprocessor guards, making the driver
code more easily readable.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Use the IS_ENABLED macro instead of #ifdef for CONFIG_SPI_STM32_INTERRUPT
when possible.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
Rework FIFO handling for full- and half-duplex transfers to prevent
RxFIFO overruns. Read pending RX data before sending new TX data and
drain the RxFIFO at end of transfer.
Use explicit equality checks for each transfer direction to make the
FIFO handling workflow clearer.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
For H7-like devices, it is possible to set the SPI size transfer prior to
starting the communication. It is useful to increase performance,
especially when combined with the use of the FIFO threshold.
But this size is limited and can't be arbitrarily high (depending on SoCs
and SPI instances, it is typically either 65535 or 1023).
When the transfer size exceeds this limit, the driver now automatically
fallback to the unlimited transfer option instead of returning an error.
Although performance are inferior in this case, at least the transfer
takes place.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
For H7-devices in full-duplex master mode, seed one initial SPI frame at
transfer start instead of relying on the TXP flag only for the first
transfer. Now only DXP and EOT flag are used (in both polling and IT).
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
In the STM32 SPI driver, buffers in cache are not supported in DMA mode.
Instead of returning an error in such cases, fallback to interrupt or
polling mode so that the transfer still takes place.
Replace the error message by a warning.
Also move the asynchronous check after the cache one to avoid falling
back to polling mode while in asynchronous mode.
Signed-off-by: Guillaume Gautier <guillaume.gautier-ext@st.com>
The dedicated DLM region is shared by hardware crypto
algorithms (SHA, RSA...etc), rather than being used
exclusively by SHA-256. Therefore, this change renames
`SOC_IT51XXX_SHA256_HW_ACCELERATE` to
`SOC_IT51XXX_HW_CRYPTO_ACCELERATE`.
Signed-off-by: Ren Chen <Ren.Chen@ite.com.tw>
This commit introduces SHA completion interrupt handling
instead of disabling global interrupts and polling the status
register. It also stores the register base and synchronization
state (semaphore) in the device configuration and device
data structures, respectively.
Signed-off-by: Ren Chen <Ren.Chen@ite.com.tw>
List the MMC counters of the Ethernet controller found in the NXP MCX
E31 and S32K3 series so they are reported as vendor specific Ethernet
statistics.
The controller of the MCX N and MCX A series has no MMC counters.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
List the MMC counters of the Ethernet controller found in the Rockchip
RK3588 so they are reported as vendor specific Ethernet statistics.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Separate the parts of RK3588_GMAC_DEFINE() with empty lines, put each
member of the struct dwmac_config initializer on a line of its own and
move the closing brackets of the multi-line initializers to their own
line. No functional change.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
List the MMC counters of the Ethernet controller found in the STM32
series so they are reported as vendor specific Ethernet statistics.
The STM32F1, F2, F4 and F7 series implement six counters, the STM32C5,
H5, H7, H7R/S and MP13 series add the four LPI counters and the STM32N6
series further adds the six frame preemption counters.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
List the MMC counters of the Ethernet controller found in the Infineon
XMC series so they are reported as vendor specific Ethernet statistics.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Expose the MAC management counters of the QoS core as vendor specific
Ethernet statistics, the same way the 10/100/1000 core does: the
platform glue lists the counters it implements and platforms without a
list report no vendor statistics.
Implement get_stats_type instead of get_stats to avoid an expensive
read of all vendor statistics from the hardware: the Ethernet L2
fetches the common statistics for every packet, while the counter
registers only need to be read when the vendor specific statistics are
requested.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Expose the MAC management counters (MMC, also called RMON counters) of
the 10/100/1000 core as vendor specific Ethernet statistics. They are
available whenever CONFIG_NET_STATISTICS_ETHERNET_VENDOR is enabled.
Which counters exist depends on the IP version and its configuration,
so the platform glue lists them with DWMAC_MMC_COUNTERS_DEFINE().
Platforms without a list report no vendor statistics. The keys follow
the names the Linux stmmac driver reports through ethtool.
The counters are 32 bits wide like the reported values, so they are
read as they are and left to roll over; reset on read and the counter
interrupts are not used.
Implement get_stats_type instead of get_stats to avoid an expensive
read of all vendor statistics from the hardware: the Ethernet L2
fetches the common statistics for every packet, while the counter
registers only need to be read when the vendor specific statistics are
requested.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
The MAC management counters run from reset and their interrupt mask
registers reset to zero, that is unmasked. A counter reaching half or
full scale sets the MMC interrupt flag in MAC_Interrupt_Status. As that
flag has no enable bit in MAC_Interrupt_Enable, it drives the interrupt
line regardless and stays set until the counter is read.
dwmac_mac_irq() never reads the counters, so the interrupt would never
deassert.
Mask all MMC interrupts unconditionally.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
The MAC management counters run from reset and their interrupt mask
registers reset to zero, that is unmasked. A counter reaching half or
full scale sets the MMC interrupt flag in DMASR. As that flag has no
enable bit in DMAIER, it drives the interrupt line regardless and stays
set until the counter is read. dwmac_isr() never reads the counters, so
the interrupt would never deassert.
Mask all MMC interrupts unconditionally.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Add the registers of the MAC management counters (MMC, also called RMON
counters): the control register, the interrupt status and mask registers
and the counters.
The block has the same layout in the 10/100/1000 core and in the QoS
core, at offset 0x100 and 0x700 respectively, so the registers are
defined once relative to a per core DWMAC_MMC_BASE.
Assisted-by: Claude:claude-fable-5.1
Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
Report every touch point the controller returns as its own multitouch
slot and track the touch IDs across scans to generate release events,
following the gt911 driver. CONFIG_INPUT_FT5336_MAX_TOUCH_POINTS caps
the number of points and defaults to 1, preserving the previous single
touch behavior.
Built for native_sim, not tested on hardware.
Assisted-by: Claude:opus-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
The track ID sits in bits 7:4 of REG_Pn_YH, but the mask handed to
FIELD_GET() selected bits 3:0, so the high nibble of the Y coordinate
was read as the touch ID.
Assisted-by: Claude:opus-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
close() sent its vendor-specific reset command with
bt_hci_cmd_send_sync(), that is, through the Bluetooth Host. The Host
is only one possible user of the driver, which therefore cannot rely on
it, and close() was for that reason compiled only into builds with a
Host, leaving a controller-only build with a transport it could open
but not close. It did not work with the Host either: bt_disable() marks
the transport closed before it calls close(), after which the Host
refuses the command with -EHOSTDOWN, so bt_disable() failed.
Send the command with the HCI lockstep helper over the driver's own
transport instead, as open() does for its commands. The receive thread
is still running at that point and feeds the response to the helper; it
is stopped afterwards, as before. With that the driver calls no Host
API any more, and close() is part of every build.
Build-tested on nucleo_wb55rg with the peripheral_hr and hci_uart
samples. Not run on hardware.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Send the two vendor-specific initialization commands, the public
address derived from the device UID and the transmit power level, from
within open(), through the HCI lockstep helper and the driver's own
send path, instead of implementing the setup() driver API op on top of
the Host's bt_hci_cmd_send_sync(). The responses are consumed in the
driver's receive thread by feeding received packets to the lockstep
helper before delivering them to the host.
The commands no longer depend on the Host, so they now also run in
controller-only builds, where they were both compiled out and never
reached, bt_enable_raw() opening the driver without calling setup(), so
the controller kept its default address and transmit power. The driver
no longer selects BT_HCI_SETUP. A failing or unanswered command fails
open() with an error instead of failing the Host's HCI initialization
later, and is logged by the helper.
A failed address command fails open(), as it has failed setup() since
commit 19c58a5a3b ("Bluetooth: ipm_stm32wb: Fail setup when the
address write fails"). open() aborts the receive thread it started when
the vendor initialization fails, so that a second bt_enable() does not
create a thread that is still running.
When open() restarts the coprocessor after a close(), it also restores
the helper's initial command allowance with bt_hci_lockstep_reset():
the restarted coprocessor allows one command again without announcing
it.
The raw send path is factored out of send() and takes the device, so
that it serves both the send() op and the helper.
close() still sends its reset command through the Host and stays behind
CONFIG_BT_HCI_HOST.
Build-tested on nucleo_wb55rg with the peripheral_hr sample. Not run on
hardware.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
This context register's content is preserved on resets. Add functions to
read and write it.
Signed-off-by: Sergei Ovchinnikov <sergei.ovchinnikov@nordicsemi.no>
Everything the reference needs beyond its output being enabled -- the
clock, the compensation and chopping settings, the internal regulator, the
trim -- is written once from init and then only lost to a reset of the
block. A power domain that goes down resets it, and the suspend-to-RAM
resume path does not re-run driver init, so the consumers came back to a
reference whose registers were at their reset values while the driver
believed it had configured them.
Register a PM action and run the same configuration sequence from TURN_ON.
Whether the output is on stays with the consumers through the regulator
reference count and not with the SoC power state, so SUSPEND and RESUME
have nothing to do: a consumer that keeps converting in a low-power state
needs its reference to keep running.
The trim needs one more thing to survive. A value asked for through
set_voltage() is the consumer's choice of output voltage and nothing else
puts it back, so remember it and restore it instead of the reset value.
Where the reset value is a factory trim, leaving the register alone is what
the driver already did, so name that condition rather than deriving it
twice from the same SDK feature macro.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
The reference is configured in one sequence from init: the clock gate, the
compensation and chopping settings, the internal regulator and the trim.
None of it is touched again for the lifetime of the driver.
Move that sequence into a helper and leave init with the regulator
bookkeeping around it, so the configuration can be run again on its own.
No functional change.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
A Cortex-M system timer that stops in a low-power state hands timekeeping
to the counter named by /chosen/zephyr,system-timer-companion, and the
companion hooks arm that counter through counter_set_channel_alarm().
Without alarm support this driver answers -ENOTSUP, so the sleep is entered
with nothing scheduled to end it: on every MCXA and MCXN board, where
LPTMR0 is that companion, a build with CONFIG_PM never comes back from its
first deep state.
Default the option on when this timer is the chosen companion. The
top-value operation it gives up is not usable in that role anyway.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
The PORT pin-mux registers only answer while the block is clocked, and a
power domain that goes down takes the clock gate with it: it comes back
closed. Every driver that re-applies its pinctrl state on the way back up
writes through those registers, so it faults on an unclocked block, and a
board whose pads are not restored has no console to report it with.
Give the driver a PM handler that re-opens the gate from TURN_ON. The pad
configuration itself is state and not activity -- it has to hold for as
long as the block is powered, whatever the rest of the SoC is doing -- so
SUSPEND, RESUME and TURN_OFF have nothing to do.
Init keeps enabling the clock itself rather than leaving it to TURN_ON.
Drivers apply their pin state from their own initialisation and none of
them claims this device first, so the gate has to be open before any of
them runs, while a device sitting in a power domain is only handed TURN_ON
once something resumes the domain -- which for a domain that only tracks
SoC power states may be much later, or never.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
The block's clock gate is opened from one place, initialisation, and is
about to be opened from a second. Lift it into a function of its own so
both callers share the error handling instead of repeating it.
No functional change.
Signed-off-by: Zhaoxiang Jin <Zhaoxiang.Jin_1@nxp.com>
The build warning caused twister error on stm32h5 boards
It can now be removed as all the stm32h5 boards have the MSPI
controller compatible.
Simply add a comment in the flash xspi driver to notify that
the flash stm32 xspi driver will be deprecated v4.5.0
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Before NPCX4, two deep sleep sub-states have to be listed in
cpu-power-states because the 'Instant' wake-up path is only valid for
a residency shorter than 200 ms:
- suspend_to_idle0: Deep Sleep with 'Instant' wake-up
- suspend_to_idle1: Deep Sleep with 'Standard' wake-up
The PM policy picks between them from the min-residency-us property,
so a sleep the kernel expects to last longer than 200 ms falls back to
the standard wake-up sub-state.
NPCX4 and later lift that restriction with PMCSR bit 4, reserved on
earlier series, so 'Instant' wake-up can be used for an unlimited
residency. Describe the capability with a new
"nuvoton,npcx-power-state" binding that extends "zephyr,power-state"
with an "unlimited-instant-wakeup" property, and pass it down to the
clock controller.
suspend_to_idle0 alone would therefore give the best power figures on
NPCX4.
However, erratum 2.21 prevents that when eSPI is in use: two eSPI
transactions issued shortly after the EC entered Deep Sleep with
instant wake-up can produce a CRC error. Boards with eSPI enabled
must select one of
- suspend_to_idle1: Deep Sleep with 'Standard' wake-up
- suspend_to_idle2: Sleep, added here, which keeps HFCLK running
so npcx4.dtsi keeps cpu-power-states at suspend_to_idle1 and leaves
the other two sub-states for boards to opt into.
Assisted-by: Copilot:claude-opus-5
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
- Add DMA support for SPI on RZ/A3UL since the previously supported
had not supported DMA.
Signed-off-by: Quang Le <quang.le.eb@bp.renesas.com>
Signed-off-by: Tien Nguyen <tien.nguyen.zg@renesas.com>
Add new LIN controller API and LIN skeleton driver.
This device driver complies with the LIN CiA Specification rev2.1
and implement the physical layer and a part of the data link layer.
The LIN skeleton code is also included as the starting point for
LIN driver development
Signed-off-by: The Nguyen <the.nguyen.yf@renesas.com>
Two-line copyright notices were wrapped in the SPDX "<text>...</text>"
construct, which is only valid in an SPDX document, not a file header.
Some notices did not have SPDX tags.
Remove the markers and tag the continuation line. Holder, year and
e-mail are left unchanged; only the syntax is fixed.
Signed-off-by: Wheeler Keith (ES ICW SW MTP EE) <Keith.Wheeler@infineon.com>
The new SDHC API driver for the STM32 SDMMC IP does not work across the
entire family portfolio, as some series (STM32F1/F2/F4/F7/L1) and lines
(STM32L4; but not STM32L4+!) use a different IP from the one which this
driver was tested against. Prevent enabling the driver on such series
since it will not work properly, or in fact build at all, because the
peripheral is called "SDIO" instead of "SDMMC" on most of these series
and the HAL/LL namings follow suit.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
irq_rx_enable() took the lock for as long as the receiver was armed.
A shell enables RX once and never disables it, so light sleep never
runs.
Take the lock only for an async RX transfer. Bytes that arrive while
the SoC sleeps are dropped; the UART is not a wake source.
Assisted-by: Grok:4.6
Signed-off-by: Raffael Rostagno <raffael.rostagno@espressif.com>
uart_irq_tx_disable() dropped the lock as soon as the driver stopped
asking for more data. Bytes can still be in the FIFO at that point,
so the SoC could enter light sleep mid-frame.
Wait for TX_DONE instead, which poll_out() already does. Rename
TX_POLL to TX_DRAIN and share it, as both paths wait for the same
event: the transmitter going empty. If TX is already idle, mask
TX_DONE and drop the lock now: the interrupt will not fire, and
leaving it enabled would keep a stale mask across the next transfer.
Assisted-by: Grok:4.6
Signed-off-by: Raffael Rostagno <raffael.rostagno@espressif.com>
