this commit adds HEAP_MEM_POOL_ADD_SIZE_SDHC_STM32_SDMMC with
a default value of 2048 bytes for sdhc driver.
Signed-off-by: Sara Touqan <zephyr@exalt.ps>
virtq_create() only checked split virtqueue size constraints with
assertions. Builds with assertions disabled therefore accepted
non-power-of-two sizes, even though ring indexing relies on that
invariant, and did not report oversized queues consistently.
Reject invalid sizes with -EINVAL before allocating memory. Keep
zero-sized unused queues supported, exercise multiple invalid boundary
cases with assertions enabled, and cover representative native and QEMU
platforms.
Assisted-by: ChatGPT:GPT-5.6 Sol
Signed-off-by: Alejandro Sánchez <alesangreat@gmail.com>
Implement the initialization hook of the Low-Power Counter Companion
Interface in the Counter API-based implementation. From this hook, we
assert that the device was configured as a potential wake-up source in
DTS and enable it as wake-up source at runtime. While we cannot prevent
an external caller from disabling the counter as wake-up source, we can
detect this and panic the kernel via an __ASSERT() to help developers
figure out their application has an error.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Update relevant drivers to invoke the newly defined hook of the
Low-Power Companion Interface during initialization.
Only two drivers currently support the Low-Power Companion:
- cortex_m_systick
- mcux_os
In the Cortex-M SysTick case, the initialization hook is called from the
"system_timer_generic" code used by that driver so that all driver based
on this shared code will also invoke the init hook appropriately if they
are ever updated to implement Low-Power Companion support.
In the MCUX OS timer case, the "system_timer_generic" code is not used
so the initialization hook is called directly from the driver.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Add a new hook to the System Timer Low-Power Companion Interface that
must be called by the System Timer driver during its initialization.
This can be used to perform one-shot configuration that may be required
by the platform implementation.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
Remove dependency of CONFIG_SYSTEM_TIMER_LPM_COMPANION_NONE (and the
associated choice) on SYSTEM_TIMER_HAS_LPM_COMPANION_SUPPORT. This makes
the option visible in every build, regardless of whether the companion
timer is supported or not, which allows using the option as an indicator
of whether or not a companion timer is used:
- CONFIG_SYSTEM_TIMER_LPM_COMPANION_NONE=y: companion timer not used
(either unsupported by systimer driver, or not available/enabled)
- CONFIG_SYSTEM_TIMER_LPM_COMPANION_NONE=n: companion timer used
This change will allow simplifications in common code since it is no
longer necessary to check for HAS_COMPANION_SUPPORT before looking at
CONFIG_SYSTEM_TIMER_LPM_COMPANION_NONE.
While at it, update the relevant header to make this explicit: the API
is not available when there is no low-power companion configured, which
is now when CONFIG_SYSTEM_TIMER_LPM_COMPANION_NONE=y.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
An auto-reload 32-bit down-counter: a RELOAD backend. The driver keeps
its synthesized cycle count and the reprogram that recovers the cycles
passing between reading the counter and rewriting it, the val1/val2
drift compensation, now named timer_driver_cycle_get() and
timer_driver_set_reload(). The core takes over the tick accounting:
announced_cycles and last_elapsed leave the device data, and with them
the deadline-to-cycles math, the range clamp and the announce.
The counter is not free-running, it counts one programmed interval at a
time, so the synthesized read is not atomic against the ISR and the
reprogram path. TIMER_CORE_COUNTER_NONATOMIC has the core serialise
sys_clock_cycle_get_32() under the clock lock.
The arm range narrows to the core default, half the synthesized count's
span, from the full 32-bit interval the hardware can hold: a full-span
interval wraps that count.
The driver states no cycles-per-tick of its own: MIN_DELAY_CYCLES and
the one-tick interval at init both read the core's
TIMER_CORE_CYC_PER_TICK.
The special case for CONFIG_SYSTEM_CLOCK_SLOPPY_IDLE goes away. It armed
the longest interval the hardware could hold on SYS_CLOCK_MAX_WAIT,
which is also an ordinary capped timeout, so a far deadline was treated
as no deadline. The core arms the longest interval it allows once
nothing is pending, through the weak sys_clock_no_timeout().
Tested on mps2/an385, which needs a devicetree overlay pointing
/chosen/zephyr,system-timer at the arm,cmsdk-timer node plus
CONFIG_CORTEX_M_SYSTICK=n: timer_api passes. The sloppy-idle variant
hangs in test_timeout_abs, which reproduces without this commit, so the
platform is not added to that variant.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The block read and block process call transfers in the STM32 SMBus
driver let the peripheral choose how many bytes it sends. The count
byte is read into the length field of the following i2c_msg, and that
message then reads straight into the buffer the caller supplies, so a
peripheral reporting up to 255 bytes writes past the end of a buffer
the API documents as holding at most SMBUS_BLOCK_BYTES_MAX (32)
bytes.
There is no point between the two reads at which the driver can
intervene, since both are messages of a single i2c_transfer(), so
receive the data into a driver-local buffer large enough for any
count a peripheral can report and copy it out only once the count is
known to fit. An over-long count returns -ENODATA without touching
the caller's buffer, matching what the PCH driver does in the same
situation.
This costs 255 bytes of stack while a block read is in flight. The
alternative, splitting the length byte and the data into two
transfers, is cheaper but gives up the bus in between and so changes
what appears on the wire.
The PEC helpers are unaffected: they walk the message array and see
the same address, count byte and data bytes as before.
Assisted-By: Claude:opus-5
Signed-off-by: David Brown <david.brown@linaro.org>
The syscall verifiers for smbus_block_read() and smbus_block_pcall()
check the count arguments they are handed but never check the receive
buffer those calls fill in. A user mode caller can therefore pass any
pointer as buf or rcv_buf and the driver writes through it in
supervisor mode without anything having proved the memory is writable
by that thread.
Unlike smbus_block_write(), which sizes its read check from the
caller supplied count, the read side has no caller supplied length to
size a check from: the peripheral decides how many bytes it sends, so
the length is not known when the verifier runs. Check the documented
worst case instead, SMBUS_BLOCK_BYTES_MAX, which is what the API
already requires the buffer to be. A fixed size check is the usual
shape in this situation (see the flash and hwinfo handlers).
This tightens the contract for user mode callers, deliberately. A
user thread that passes a receive buffer shorter than
SMBUS_BLOCK_BYTES_MAX, in a region that is not writable past the end
of that buffer, now takes a K_OOPS instead of silently having memory
written past the buffer. Supervisor callers do not go through the
verifiers and are unaffected.
Assisted-By: Claude:opus-5
Signed-off-by: David Brown <david.brown@linaro.org>
This property is now defined on the parent MFD device. Having
it in the GPIO driver means that other MFD children may inadvertently
be reset.
Signed-off-by: James Bennion-Pedley <James.Bennion-Pedley@thinksmartbox.com>
This is an 8-bit linear current source LED dimmer that
is built into the AW9523B I2C IO Expander.
This is the other mfd function alongside the GPIO_AW9523B
driver. This one also supports runtime power management (so can be
placed on a power domain).
Signed-off-by: James Bennion-Pedley <James.Bennion-Pedley@thinksmartbox.com>
Adds reset GPIO to the MFD parent (as having reset on gpio/led nodes
will reset each other). Also adds PM support so device can be on
a power domain.
Signed-off-by: James Bennion-Pedley <James.Bennion-Pedley@thinksmartbox.com>
The XEC central DMA channel has no block-chain hardware: completion is
just MEM_ADDR reaching MEM_ADDR_END. Cache the dma_block_config chain
from configure() into a per-channel array (dma_xec_block[]) and program
only one block into hardware at a time. On each DONE, the ISR decides
whether to chain to the next cached block or terminate; cyclic wraps
back to block 0 instead of terminating after the last block.
Chaining reprograms the address registers from the ISR without tearing
down IENABLE/ACTV/GIRQ state, but per HW guidance for erratum
SCG_MR_22NM-131, a still-pending peripheral request can spontaneously
restart the channel the instant a raw reprogram makes MSA < MEA true
again, so dma_xec_chan_reprogram() forces the channel to HW idle via
ABORT (bounded to one unit-size AHB transfer) before rewriting
addresses.
Add DMA_MCHP_XEC_MAX_BLOCKS_PER_CHAN (default 1) to size the cached
block array; the default preserves today's single-block behavior and
RAM footprint bit-for-bit. reload() always re-arms a single buffer, so
it resets num_blocks/cur_block/cyclic to drop any chain left over from
a prior multi-block configure().
Signed-off-by: Manimaran A <manimaran.a@microchip.com>
Assisted-by: Claude:claude-opus-4-8
Introduce dma_xec_chan_reset() and use it from configure, reload and
stop to remove duplicated abort/clear sequences. Move channel
activation and interrupt enable from configure() to start(), so a
channel is armed only when a transfer actually begins.
Signed-off-by: Manimaran A <manimaran.a@microchip.com>
Derive pending_length from the memory end/start registers,
report total_copied as 0, and drop the now-unused counters.
Signed-off-by: Manimaran A <manimaran.a@microchip.com>
Assisted-by: Claude:claude-opus-4-7
Make the DMA driver API entry points follow the Zephyr contract and
validate input:
- config/reload/start: add xec_dma_chan_is_busy(), which requires both
the BUSY bit and a HW/SW flow-control run bit (BUSY alone can be set
without a transfer running), and route the -EBUSY guards through it.
- config: also reject zero-size blocks, half-complete callbacks,
mismatched handshake modes and invalid data sizes; drop the unused
block head/curr pointers.
- get_status: return -EIO on a latched bus error (hw_status is volatile).
- get_attribute: also report buffer address/size and copy alignment and
NULL-check the output.
- chan_filter: use enum dma_channel_filter and bounds-check the channel.
- stop: clear the GIRQ source latch to avoid a spurious pending interrupt.
Signed-off-by: Manimaran A <manimaran.a@microchip.com>
Assisted-by: Claude:claude-opus-4-8
Generate the per-channel ISRs and IRQ_CONNECT calls by iterating the
interrupt-names property instead of girqs, so the loop index aligns 1:1
with the interrupts entries, and look up the GIRQ enable from the config
by channel index. Mark interrupt-names required and name the mec172x DMA
channels chan0..chan15.
Signed-off-by: Manimaran A <manimaran.a@microchip.com>
The generic timer core already extends this driver's 32-bit count from its
announce baseline, so sys_clock_cycle_get_64() works. Without the select,
k_cycle_get_64() returns 0.
Assisted-by: Claude:opus-5
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Commit ed7dd4f011 ("drivers: serial: stm32: split cyclic RX wrap into two
contiguous events") fixed some issues with cyclic wraparound,
but left a race condition where if the timeout arrives before COMPLETE,
data is emitted twice.
Simplify handling by ignoring the status and always using
`dma_get_status` to determine how much data to emit.
Return an error when trying to enable cyclic DMA with a 1-byte buffer.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Kamil Krzyżanowski <kamnxt@kamnxt.com>
The STM32MP13 DMA_InitTypeDef structure does not contain the Channel
member used by STM32 DMA V1 devices. It provides a Request member,
similar to the STM32H7 DMA HAL implementation.
Signed-off-by: Fabrice DJIATSA <fabrice.djiatsa-ext@st.com>
z_isr_install() is reached with the isr table index, which on a
SoC that reserves table entries sits above the line the enabled
mask uses, so the shift ran past the end of the mask and reported
an unrelated line. Subtract the reserved offset before the
lookup.
The offset symbol depends on GEN_ISR_TABLES, which the low power
cores turn off, so guard the subtraction the same way the rest of
the driver does.
Enable and disable are called with the line itself and are left
alone.
Assisted-by: Claude:opus-5
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
clock_check_subsys() bounds the GCLK peripheral channel of a subsystem
by GCLK_PH_MAX, which is 47. PIC32CZ CA has 64 PCHCTRL channels: the
ATDF gives PCHCTRL a count of 64 on every CA80, CA90 and CA91 part,
the HAL defines GCLK_NUM as 64, and the dt-bindings header assigns
channels up to 63.
Every GCLKPERIPH subsystem above channel 47 is therefore rejected:
CAN2 to CAN5, GMAC_TX, GMAC_TSU, SQI0, SQI1, SDHC0, SDHC1, MLB and
CM7_TRACE. For those, clock_control_on(), clock_control_off(),
clock_control_get_rate() and clock_control_configure() return
-ENOTSUP, and clock_control_get_status() reports
CLOCK_CONTROL_STATUS_UNKNOWN. Found on a PIC32CZ CA90 Curiosity Ultra,
where the CAN3 and CAN4 drivers failed to initialize with -ENOTSUP
from clock_control_on().
Derive the bound from GCLK_NUM so it follows the hardware.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Arkadiusz Grzelka <devitwise@gmail.com>
With DMA no IADC interrupt is enabled, so the error flags are never
looked at: reading a channel whose analog bus is not allocated to the
IADC returns 0 with a meaningless sample. iadc_start_scan() also
ignores a failure of iadc_dma_start(), which leaves the reader blocked
forever, and the DMA callback neither stops the channel nor the scan
when a transfer fails.
Enable the error interrupts, with and without DMA, and check the error
flags in the DMA callback as well. As the interrupt handler and the DMA
callback can now both end a sampling, let iadc_sampling_end() decide
which of them does: it masks the IADC interrupts and stops the scan and
the DMA channel, so that an error that persists cannot interrupt again
for the same sampling, and it lets only the first caller complete it.
The interrupt handler ends the sampling before it clears the error
flags, as the DMA callback may preempt it and looks at them too. A
failed sampling stops the interval timer on every path now.
Tested on an EFR32MG24 (BRD4186B) with and without DMA, with immediate
and with deferred logging: a channel on an unallocated analog bus,
alone, with extra samplings and as one entry of a scan at 1024x
oversampling, and in a sequence with an interval, fails with -EIO and
one logged error, and the reads that follow are correct. Interrupt
priorities that let the DMA callback preempt the IADC handler were not
tested.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Without DMA the scan FIFO is read out in the SCANTABLEDONE interrupt,
but it holds only 8 results (4 on xG21, xG22, xG27 and xG29) while a
sequence may name up to 16 channels. A longer sequence overflows the
FIFO: the first results are delivered, the rest is lost and the read
fails with -EIO.
Reading the FIFO out on its data valid level interrupt instead would
depend on interrupt latency, with a conversion taking as little as a
few microseconds. Convert the channels of a sampling in parts that fit
the FIFO instead, starting the next part from the interrupt that read
out the previous one. The DMA path is unchanged.
Tested on an EFR32MG24 (BRD4186B): sequences of 9 and 16 channels,
300 reads of 16 channels with four distinct inputs checked sample by
sample, a 9 channel subset with extra samplings, and 9 channels at 20-bit
resolution.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
When a scan ends with an error flag set, iadc_isr() first calls
adc_context_on_sampling_done(), which completes the sequence, and then
adc_context_complete() with -EIO. The first completion wakes the
reader, the second one leaves the context's semaphore signaled. Every
following adc_read() then takes that stale signal, returns 0 before its
own conversion has run and gets its buffer filled by the ISR after the
call has returned, which leaves the semaphore signaled once more. Later
errors are reported as success for the same reason, and a sequence with
extra samplings keeps sampling after the error.
Handle the error first and return, so that a sequence is completed
exactly once. adc_context_complete() does not stop the timer of a
sequence with an interval the way adc_context_on_sampling_done() does,
so stop it here: left running, it makes later reads fail with -EBUSY.
Seen on an EFR32MG24 (BRD4186B) with a scan FIFO overflow and with a
channel whose analog bus is not allocated to the IADC: the reads after
the failing one returned 0 with their buffers untouched. With this
change every failing read returns -EIO and the following reads are
correct.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Return -ENOSYS instead of -EINVAL for selection targets other than
VIDEO_SEL_TGT_CROP, since these operations are not implemented by
the driver.
This lets video_set_compose_format() proceed with format configuration
through set_format instead of aborting with -EINVAL.
Signed-off-by: Daniele Cloralio <d.cloralio@arduino.cc>
Avoid k_msleep while ITS initializes in PRE_KERNEL_1. The system
clock and scheduler are not ready, so delayed quiescence can halt boot.
Use k_busy_wait for the existing one millisecond polling interval.
This retains the timeout behavior without a scheduler dependency.
Fixes#119809
Signed-off-by: Hongquan Li <hongquan.li@processmission.com>
Make the native_sim Wi-Fi driver devicetree-instantiated and opt-in, and
take its MAC address from devicetree instead of Kconfig.
Previously CONFIG_WIFI_NATIVE_SIM defaulted to y for any ARCH_POSIX build
with the supplicant, so it was pulled into unrelated builds (e.g.
tests/net/wifi/wifi_nm and tests/net/wifi/configs). The fallback MAC was
chosen by Kconfig, and CONFIG_WIFI_NATIVE_SIM_SUPPLICANT_CONF_FILE was
dead (host_wifi_drv_init() ignored it now that only the Zephyr
supplicant runs).
Add a "zephyr,native-sim-wifi" binding (including ethernet-controller.yaml
for the MAC properties) with a required "host-interface" string, and
instantiate the driver with DT_INST_FOREACH_STATUS_OKAY /
ETH_NET_DEVICE_DT_INST_DEFINE. The driver now depends on
DT_HAS_ZEPHYR_NATIVE_SIM_WIFI_ENABLED, so it is built only when a node is
present - add one via an overlay to enable it.
The host interface name comes from the "host-interface" property and the
fallback MAC from "local-mac-address" / "zephyr,random-mac-address" (the
driver still overrides it with the host interface MAC at init). Remove
the WIFI_NATIVE_SIM_INTERFACE_COUNT, _DRV_NAME, _RANDOM_MAC, _MAC_ADDR
and _SUPPLICANT_CONF_FILE options and the now-unused config_file argument
of host_wifi_drv_init().
The interop test gains a native_sim.overlay defining the node
(host-interface = "zwifi", random MAC).
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Connecting sometimes hung with an endless flood of
"nl80211: send_and_recv->nl_recvmsgs failed: -4 (Try again)". -4 is
libnl NLE_AGAIN: the non-blocking netlink socket has no data and
hostap's send_and_recv() busy-loops until the command's ACK arrives.
The host adapter runs two threads: the eloop thread (host_handler)
services the nl80211 event sockets, including bss->nl_connect, while the
Zephyr supplicant thread issued the authenticate/associate/deauthenticate
ops with send_and_recv() on that same bss->nl_connect socket. When a
connect command ran on the Zephyr thread while the eloop thread was also
reading bss->nl_connect, the eloop could consume the command's ACK,
leaving send_and_recv() spinning on NLE_AGAIN forever. It was
intermittent because it is a race over which thread reads the socket
first.
Run those three MLME commands on the thread that owns the netlink
sockets instead. A small command-handoff (cmd_fd/cmd_done_fd socketpair
plus pending_cmd) lets the Zephyr caller publish a request, wake the
eloop, and block until the eloop thread has executed the op; the
argument is passed by pointer since both threads share one address
space. With a single thread doing the netlink I/O there is no concurrent
reader to steal the ACK.
Only the bss->nl_connect commands are marshalled. Scan and the other
ops use global->nl, which the eloop does not service, so they are not
raced and stay on the Zephyr thread; moving the scan path onto the eloop
thread was observed to starve event processing and perturb scan timing.
Tested on native_sim against the net-tools mac80211_hwsim setup: the
interop test passes 5/5 across repeated runs and rapid connect/disconnect
cycles no longer produce the "Try again" flood.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Add a Wi-Fi driver for the native_sim board so the Zephyr Wi-Fi stack
(network manager / wpa_supplicant, net_mgmt, the wifi shell) can be
exercised on the host against the Linux mac80211_hwsim simulated radio.
It is meant for development and verification of the Wi-Fi APIs, not as a
driver for any real hardware.
The Zephyr wpa_supplicant is the sole SME. The driver's host side brings
up only the Linux nl80211 driver (compiled for the native_simulator
runner) and runs its event loop in a thread; it does not run a second,
host-side supplicant. It provides its own wpa_supplicant_event() that
forwards nl80211 driver events (scan results, auth, assoc, deauth,
disassoc, mgmt rx) to the Zephyr supplicant over an in-process
socketpair, read by the interface RX thread and dispatched to the
supplicant callbacks. The supplicant driver ops (scan, authenticate,
associate, set_key, get_capa, ...) call the nl80211 ops table directly.
Data frames, including the EAPOL 4-way handshake, flow over an AF_PACKET
socket bound to the host interface and the Zephyr networking stack.
Notes on the host integration:
- The Zephyr interface adopts the host radio MAC address, so frames
addressed to the associated STA are accepted by the Ethernet L2 and
the frames it transmits are not rejected by the AP.
- control-port-over-nl80211 is disabled in the driver capabilities so the
kernel delivers EAPOL as data frames to the supplicant's l2_packet.
- The interface uses carrier-up plus dormant, leaving dormant on
association so the handshake can use the data path, and re-entering it
on disconnect.
- A small supp_api hook lets the supplicant connect path notify this
proxy driver; the connection itself is driven by the Zephyr SME.
Tested on native_sim with mac80211_hwsim: scan, connect (open and
WPA2-PSK), status, disconnect and data transfer all work.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Add implementation of optional led driver API function named
write_channels. The purpose of this function is to allow the caller
update multiple channels in a single call.
Signed-off-by: Hubert Miś <hubert.mis@gmail.com>
mspi_stm32_ospi_hal_address_size() returns HAL_OSPI_ADDRESS_* values,
but mspi_stm32_ospi_access() compares it against
HAL_XSPI_ADDRESS_24_BITS, which only exists in the XSPI HAL. This
breaks the build on STM32H7 (e.g. stm32h735g_disco with
samples/drivers/mspi/mspi_flash). Use HAL_OSPI_ADDRESS_24_BITS
instead.
Signed-off-by: Filip Stojanovic <filipembedded@gmail.com>
The current `get_entropy_isr()` implementation is not re-entrant and has
in fact a very high chance of deadlocking because the logic that checks
if we should disable the RNG after generating entropy is inverted: the
RNG is considered as "acquired" for ISR polling when its interrupt is
ENABLED but get_entropy_isr() DISABLES the IRQ line...
Inverting the logic seems like it can fix the problem but it would still
be flawed: the sole information of whether IRQs are enabled or not isn't
sufficient to handle all cases.
Associate the RNG being enabled to a usage count (protected by spinlock)
to ensure that the RNG is enabled atomically, and we never disable it
from a high-priority ISR while a lower priority ISR was polling for
random bytes. This allows get_entropy_isr() to work re-entrantly with
a few modifications to the routine.
Signed-off-by: Mathieu Choplain <mathieu.choplain-ext@st.com>
The driver selected EXPERIMENTAL only for a subset of host SoCs. A
Kconfig symbol's maturity is a property of the whole driver, it cannot
be experimental on one SoC and supported on another. Drop the
conditional select and mark the nRF70 driver supported everywhere.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Assisted-by: Cursor:Auto
close() has been compiled only with CONFIG_BT_HCI_HOST since the driver
was added, while the driver API table has always referenced it
unconditionally, so a build of this driver without the Bluetooth Host
fails with "'bt_da1469x_close' undeclared". The function disables the
CMAC interrupt and the CMAC core and uses nothing of the Host, so drop
the guard.
Compile-tested for da1469x_dk_pro: the driver object in a
CONFIG_BT_HCI_RAW configuration, which failed before, and the
peripheral_hr sample. Not run on hardware.
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
ps8xxx_init_work_cb() ignores the results of gpio_pin_configure_dt() and
gpio_pin_interrupt_configure_dt() for the alert pin. If either fails,
the TCPC is still marked initialized and no alert is ever delivered.
Log the error and abort initialization, so tcpc_init() keeps returning
-EAGAIN, the same way the rt1715 and fusb307 drivers do.
Signed-off-by: YunHung Hua <oliverhua.us@gmail.com>
The optional vconn-disc-gpios pin is driven with gpio_pin_set_dt() to
switch the external VCONN discharge path, but the driver never
configures it. The pin stays in its reset state, usually an input, so
setting it has no effect on the pin, and a GPIO_ACTIVE_LOW flag from
devicetree is not applied either, because gpio_pin_configure_dt() is
what records it.
Configure the pin as an inactive output at init when it is defined,
the same way ucpd_numaker.c handles its discharge pins.
Build-tested only; not exercised on FUSB307 hardware.
Signed-off-by: YunHung Hua <oliverhua.us@gmail.com>
fusb307_init_work_cb() ignores the results of gpio_pin_configure_dt()
and gpio_pin_interrupt_configure_dt() for the alert pin. If either
call fails, for example because the interrupt line is already in use,
the driver still marks the TCPC as initialized and no alert is ever
delivered.
Log the error and abort the initialization instead, as is already done
when gpio_add_callback() fails. The TCPC then stays marked as not
initialized, so tcpc_init() returns -EAGAIN.
Build-tested only; the error paths were not exercised on FUSB307
hardware.
Signed-off-by: YunHung Hua <oliverhua.us@gmail.com>
The optional vconn-ctrl-gpios and vconn-disc-gpios pins are driven with
gpio_pin_set_dt() to switch the external VCONN supply and discharge
path, but the driver never configures them. The pins stay in their
reset state, usually an input, so setting them has no effect on the
pin, and a GPIO_ACTIVE_LOW flag from devicetree is not applied either,
because gpio_pin_configure_dt() is what records it.
Configure both pins as inactive outputs at init when they are defined,
the same way ucpd_numaker.c handles its discharge pins.
Build-tested only; not exercised on RT1715 hardware.
Signed-off-by: YunHung Hua <oliverhua.us@gmail.com>
rt1715_init_work_cb() ignores the results of gpio_pin_configure_dt()
and gpio_pin_interrupt_configure_dt() for the alert pin. If either
call fails, for example because the interrupt line is already in use,
the driver still marks the TCPC as initialized and no alert is ever
delivered.
Log the error and abort the initialization instead, as is already done
when gpio_add_callback() fails. The TCPC then stays marked as not
initialized, so tcpc_init() returns -EAGAIN.
Build-tested only; the error paths were not exercised on RT1715
hardware.
Signed-off-by: YunHung Hua <oliverhua.us@gmail.com>
err is declared once outside the loop that walks the pending channels,
and the path without an error flag never clears it. When one interrupt
has several channels pending and a lower-numbered one carries an error,
every higher-numbered channel handled in the same pass gets that -EIO
in its callback although its own transfer succeeded.
The hardware keeps the error flags per channel, and the other drivers
that share one interrupt across channels compute the status inside the
loop: dma_silabs_ldma sets it per channel, dma_sam_xdmac reads its own
error register for each one.
The MIPI DBI PIO driver runs up to four channels on one device for its
split configurations, which is where this is reachable.
Signed-off-by: Hsiu-Chi Tsai <hctsai@linux.com>
