Two sequencing problems in the MMC wide bus path break eMMC 4-bit
operation on hosts that program the bus width in the SDIO widebus /
clock callbacks (e.g. STM32H7):
1. The SWITCH command (CMD6) is issued before the host has switched
to wide bus operation. When the card completes the switch while
the host is still in 1-bit mode the switch never takes effect and
every following data transfer times out. Switch the host to wide
bus operation before issuing CMD6.
2. The transfer clock is selected only at the end of mmcsd_widebus(),
so the whole switch sequence runs at ID-mode clock and, on the
affected hosts, the final clock update does not take effect either,
leaving the bus at ~400 kHz. Select the MMC transfer clock before
calling mmcsd_widebus(), and pick CLOCK_MMC_TRANSFER_4BIT when wide
bus operation is active (mirroring the SD card path) so a later
clock selection cannot revert the host to 1-bit.
No behavior change for SD cards, and no change on hosts whose widebus
callback only records the requested state.
Tested on a custom STM32H743 board with eMMC: sd_bench sequential
write ~4.1 MB/s, sequential read ~6.3 MB/s (previously all data
transfers timed out).
Signed-off-by: DuoYuWang <thirteenking.wang@gmail.com>
Building the hello_d example with LDC ImportC fails because ImportC
does not correctly handle direct __uint128_t C-style casts such as
(__uint128_t)a and (__uint128_t)1.
Replace the direct casts with equivalent typed temporaries, preserving
the existing behavior while allowing hello_d to build successfully with
LDC ImportC.
Verified on sim:nsh with CONFIG_EXAMPLES_HELLO_D=y:
nsh> hello_d
Hello World, [skylake]!
DHelloWorld.HelloWorld: Hello, World!!
Signed-off-by: Ansh Rai <anshrai331@gmail.com>
dump_stacks() only checked kernelstack_sp != 0 || force, so for tasks
with no kernel stack (e.g. idle, kernelstack_base == 0) the force path
passed base 0 to dump_stackinfo() and dumped raw memory from address 0,
triggering a secondary fault that truncated the panic log. Guard with
kernelstack_base != 0.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
A crash was observed when running ps: a BusFault in nxtask_argvstr
dereferencing tl_argv, because a thread's stack overflow had silently
corrupted the TLS region where tl_argv resides.
On ARMv8-M with CONFIG_ARMV8M_STACKCHECK_HARDWARE, PSPLIM was set to
stack_alloc_ptr -- the bottom of the allocation where TLS begins. The
stack grows downward and TLS occupies [stack_alloc_ptr, stack_alloc_ptr
+ tls_info_size()), so an overflow crossed into TLS and clobbered
tl_argv before SP reached the limit, going undetected until code that
read the corrupted TLS data (such as ps) hit the bad pointer.
Set the limit to stack_alloc_ptr + tls_info_size() -- the top of the
TLS region and the usable stack base -- so an overflow faults at the
TLS boundary, before any TLS byte is touched. Include <tls/tls.h>
for the tls_info_size() macro, which is the value sched reserves for the
TLS region via up_stack_frame().
Signed-off-by: Junbo Zheng <zhengjunbo1@xiaomi.com>
The remote CPU's IPI handler wrote into the caller's buffer directly,
which may not be reachable from the target CPU's address environment
under CONFIG_ARCH_ADDRENV.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Building Zig applications on sim:x86_64 with Zig 0.13.0 fails because
the generated target "x86_64-freestanding-sysv" is not recognized by
Zig. Introduce a Zig-specific ABI mapping that translates "sysv" to
"gnu" without affecting other toolchains.
After correcting the target ABI, linking still fails due to unresolved
references to __zig_probe_stack. Add -fcompiler-rt so Zig includes the
required compiler runtime during linking.
Verified on sim:nsh with CONFIG_EXAMPLES_HELLO_ZIG=y:
nsh> hello_zig
[sim]: Hello, Zig!
Fixes#19475
Signed-off-by: Ansh Rai <anshrai331@gmail.com>
If user passes NULL as buffer, the driver may crash. This is problematic
for NuttX protected and kernel builds.
Details in the issue: https://github.com/apache/nuttx/issues/19473
While this fixes the issue with a typical NULL pointer, fundamentally this
will be addressed with the implementation of access_ok().
https://man7.org/linux/man-pages/man2/access.2.html
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
riscv_fault_handler() only checked the task type and SYSCALL flag, so a
fault taken inside an interrupt handler (running in kernel mode) was
blamed on the user task that happened to be interrupted and killed with
SIGSEGV, hiding the real kernel bug. Use the STATUS_PPP bit of the trap
frame to tell whether the fault originated from user mode: only then is
it safe to kill the task.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
riscv_fillpage() unconditionally panics the kernel on an unmappable
or invalid access, even when the fault is caused by a user task. A
user-space fault should terminate that task with SIGSEGV instead of
taking down the whole system, matching the existing behavior for
other exceptions in riscv_exception().
Signed-off-by: liang.huang <liang.huang@houmo.ai>
riscv_fillpage() is the LOADPF/STOREPF handler used under
CONFIG_PAGING. It checked whether intermediate page table levels were
already allocated, but never checked the final leaf PTE before
installing a new mapping.
RISC-V raises the same LOADPF/STOREPF cause both when a leaf PTE is
absent (a real fault) and when it is present but its permission bits
don't satisfy the access, e.g. a store to a .text page whose write
access was revoked after ELF loading. The two cases are
indistinguishable from mcause alone.
Treating both cases as "page missing" let riscv_fillpage silently
allocate a fresh, zeroed physical page over an existing mapping,
discarding the old page (a leak) and defeating whatever permission
that mapping was enforcing. Reproduced on real hardware: a user-space
store to an already-loaded .text page got a fresh writable page
instead of being rejected.
Check the leaf PTE's valid bit before allocating; if a mapping already
exists, panic instead of overwriting it.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Two related defects corrupt CDC-NCM transmit once TCP write buffers make TX
bursty (a single txavail poll drains many queued segments back-to-back through
cdcncm_send):
1. Buffer-reuse race. cdcncm coalesces datagrams into the single pre-allocated
wrreq->buf that the USB controller transmits directly from, but cdcncm_send
formatted a new NTB batch into it (cdcncm_transmit_format) without first
waiting for the previous transfer to complete -- the wrreq_idle wait happened
only later, in cdcncm_transmit_work. A new batch started while the previous
NTB was still in flight overwrote the in-flight buffer, so the host dropped
the corrupted NTB and TX could wedge (wrreq_idle never reposted).
Fix: acquire wrreq_idle in cdcncm_send when starting a new batch
(dgramcount == 0), before formatting; drop the now-redundant wait in
cdcncm_transmit_work (a second wait on the init-to-1 semaphore would deadlock).
2. Concurrent transmit_work. cdcncm_send runs under the recursive netdev_lock and
calls cdcncm_transmit_work() synchronously in the buffer-full branch, while a
scheduled delaywork instance runs cdcncm_transmit_work() on ETHWORK -- two
different threads. Two EP_SUBMITs of the one wrreq corrupt the IN request
queue and leave the IN buffer prepared-but-unarmed (controller idle,
wrreq_idle never reposted).
Fix: wrap cdcncm_transmit_work in netdev_lock (the synchronous caller already
holds this recursive nxrmutex; a delaywork instance blocks until the drain
releases it), and add an empty-batch guard (dgramcount == 0 -> return) so a
delaywork that runs after a synchronous flush emptied the batch does not seal
an empty NTB and double-submit the in-flight wrreq.
Validated on RP2350 (Pico 2 W) with CONFIG_NET_TCP_WRITE_BUFFERS=y as part of the
complete fix set: 144 dense/concurrent HTTP downloads, zero wedges, ~486 KB/s
(previously transmit hung within a few requests). On RP2350 full stability under
maximal TX density additionally requires a memory barrier between the BUFF_STATUS
clear and the AVAILABLE re-arm in the Cortex-M33 USB device driver (a separate
change); these cdcncm defects are real and the fixes correct independent of it.
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
Assisted-by: Claude (Anthropic Claude Code)
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
qemu-rv's S-mode/non-SMP setintstack unconditionally reloaded sp to
the top of the per-cpu interrupt stack. A trap taken while already
running on that stack rewound sp back to the same address, so the
nested trap's frame overwrote the still-live outer trap's frame.
Port the bounds check already used by the canonical setintstack in
riscv_macros.S: only move sp when it is outside the interrupt stack
range.
Other vendor chip.h files have the same unconditional-reload pattern
and are left for a follow-up.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Program names containing '-' (for example, renaming hello to
hello-world via PROGNAME) previously generated an invalid identifier
<NAME>_main when constructing the main= compiler definition and the
APP_MAIN target property used during builtin list generation. This
caused the CMake build to fail because '-' is not a valid character in
a C identifier.
This mirrors the Make-based fix (Application.mk's PROGSYM) for the
traditional build.
Introduce NAME_SYM, a sanitized copy of NAME with '-' replaced by '_',
and use it only where an internal C identifier is required: the
main= COMPILE_DEFINITIONS property and the APP_MAIN target property.
Leave NAME unchanged everywhere else, including CMake target/output
names and the APP_NAME property, where hyphens are valid.
The standalone/loadable executable path (MODULE/DYNLIB/kernel build)
does not rename main() and therefore requires no sanitization because
each executable is linked independently rather than merged into a
shared builtin image.
Testing (WSL2 Ubuntu, x86_64):
- BOARD_CONFIG=sim/nsh, CONFIG_EXAMPLES_HELLO_PROGNAME="hello-world":
clean CMake configure/build; 'hello-world' runs and prints
'Hello, World!!'
- Reverted to CONFIG_EXAMPLES_HELLO_PROGNAME="hello": reconfigured
and rebuilt; 'hello' runs and prints 'Hello, World!!' (no
regression)
Fixes#19447
Signed-off-by: Ansh Rai <anshrai331@gmail.com>
Three defects that together prevented macOS from ever mounting a
composite USBMSC function (Linux was mostly unaffected because its
probe sequence and recovery timing never exercised these paths):
1. usbmsc_setup() compared the class-request wIndex against the
compile-time constant USBMSC_INTERFACEID (= CONFIG_USBMSC_IFNOBASE,
i.e. 0) instead of the composite-assigned priv->devinfo.ifnobase.
In composite mode the MSC interface number is nonzero, so
GET MAX LUN, Bulk-Only Mass Storage Reset, and GET/SET INTERFACE
all failed the index check and stalled EP0. Standalone MSC is
unaffected (ifnobase == 0), which is why this went unnoticed.
2. usbmsc_deferredresponse() has its entire body inside
#ifndef CONFIG_USBMSC_COMPOSITE, so the deferred EP0 status stage
for MSRESET/SETINTERFACE was never sent in composite mode and the
host's Bulk-Only reset timed out. (Unreachable before fix 1 --
MSRESET used to stall at the wrong-interface check.) Compile the
body in composite mode too, but suppress the worker's deferred
response for SETCONFIGURATION there: the composite driver answers
that request itself, and a duplicate zero-length packet corrupts
the EP0 state.
3. usbmsc_cmdfinishstate() stalled the bulk IN endpoint whenever a
device-to-host command left a residue, even when the response had
already been sent and terminated by a short packet (or ZLP). The
stall is BOT-legal (USB MSC BOT 6.7.2) but gratuitous: the short
packet already ended the data phase and the residue is reported in
dCSWDataResidue. Hosts such as macOS answer any bulk-IN halt during
device probing with a full Bulk-Only reset sequence, which costs
seconds per command or aborts the probe entirely (macOS probes
MODE SENSE(6) with allocation lengths that exceed the response;
Linux's probe does not). Only halt the endpoint when nothing
terminated the data phase.
Root-cause analysis and host traces in apache/nuttx#19435.
Validated on RP2350 silicon (Raspberry Pi Pico 2 W, composite
CDC-ACM + CDC-NCM + USBMSC): GET MAX LUN answers 1 LUN (previously
EP0 stall and a garbage LUN count on macOS), MSRESET completes 10/10
(previously ETIMEDOUT), MODE SENSE(6) alloc=0xC0 returns short data
plus a CSW with dCSWDataResidue and zero bulk-IN stalls across the
exact-length suite, and macOS now mounts the volume (together with the
companion DCD fixes).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
blksize_t is currently defined as int16_t, which overflows when a
filesystem reports a block size larger than 32767 bytes. This causes
st_blksize to become zero, leading to an integer divide-by-zero when
st_blocks is calculated in stat().
Widen blksize_t to int32_t to support larger filesystem block sizes.
Update nuttx_blksize_t in include/nuttx/fs/hostfs.h to keep it
consistent with include/sys/types.h.
struct geometry.geo_sectorsize (include/nuttx/fs/ioctl.h) is also
typed blksize_t, so every debug print of that field using a 16-bit
format specifier is updated to PRId32 to match the new width:
drivers/misc/ramdisk.c, drivers/mmcsd/mmcsd_spi.c, drivers/mtd/ftl.c,
fs/driver/fs_blockmerge.c, drivers/mtd/smart.c,
drivers/usbhost/usbhost_storage.c, drivers/mmcsd/mmcsd_sdio.c,
arch/arm/src/s32k1xx/s32k1xx_eeeprom.c,
arch/arm/src/lc823450/lc823450_mmcl.c.
Signed-off-by: Ansh Rai <anshrai331@gmail.com>
Signed-off-by: root <root@LAPTOP-9C7LKDC5.localdomain>
Add the POSIX d_ino (file serial number) member to struct dirent and
populate it on every readdir() path, so portable callers (e.g. scp in
dropbear) that read dp->d_ino observe a meaningful, non-zero inode
number:
- include/dirent.h: declare d_ino in struct dirent and drop the
outdated comment claiming the field is unimplemented.
- include/nuttx/fs/hostfs.h: add d_ino to struct nuttx_dirent_s so
the hostfs ABI can carry the inode number across the VFS boundary.
- arch/sim/src/sim/posix/sim_hostfs.c: forward the host's
ent->d_ino into entry->d_ino.
- fs/vfs/fs_dir.c (read_pseudodir): copy the in-memory inode's
i_ino into entry->d_ino for the pseudo filesystem.
- fs/yaffs/yaffs_vfs.c: forward yaffs's dirent->d_ino into
entry->d_ino.
- fs/rpmsgfs: extend struct rpmsgfs_readdir_s with an 'ino' field
and propagate it across the RPC in both rpmsgfs_server (fills it
from the underlying entry) and rpmsgfs_client (writes it back to
the caller's nuttx_dirent_s).
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
A 16-bit ino_t can only address 65536 distinct file serial numbers,
which is not enough for filesystems with large directory trees and
breaks portable software (e.g. dropbear's scp) that expects a wider
inode number space. Widen ino_t (and nuttx_ino_t in the hostfs ABI)
to uint32_t to match common POSIX practice.
Update fs/rpmsgfs/rpmsgfs.h accordingly: promote the 'ino' field in
struct rpmsgfs_stat_priv_s from uint16_t to uint32_t and move 'nlink'
into the trailing 16-bit slot previously occupied by the reserved
field, keeping the overall packed-struct layout/size unchanged.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Move uid_t/gid_t out of the CONFIG_SMALL_MEMORY #ifdef so they are
always defined as unsigned int regardless of SMALL_MEMORY.
Update include/nuttx/fs/hostfs.h to match: drop the int16_t variants
of nuttx_gid_t/nuttx_uid_t and keep a single unsigned int definition
so the hostfs RPC ABI stays in sync with sys/types.h.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
sys_callN() wraps a bare ecall and calls no other function, so the
compiler treats it as a leaf function: with frame pointers enabled,
it only needs to spill the caller's s0, which it places in what
up_backtrace()'s fp-chain walk assumes is ra's stack slot, while the
real ra slot is never written. sched_backtrace() then misreads that
slot as the return address for this frame, either resolving to a
bogus symbol or, if the adjacent garbage happens to look
out-of-range, terminating the backtrace early.
Add "ra" to the ecall clobber list so the compiler spills/reloads ra
around the ecall like a normal call site, keeping ra and the saved
s0 in their expected slots. Gate this on
CONFIG_FRAME_POINTER && CONFIG_SCHED_BACKTRACE, the only combination
where up_backtrace()'s fp-chain walk is both valid (FRAME_POINTER)
and actually exercised (SCHED_BACKTRACE); other configurations keep
the original "memory"-only clobber and pay no extra cost.
This only fixes the syscall boundary. Leaf functions that do not
cross a syscall (e.g. up_idle()) can still lose their ra slot the
same way and are not addressed here.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
up_backtrace() on a different tcb dereferences that task's own stack
to walk its frame pointer chain, but never selected that task's
address environment first. Under CONFIG_ARCH_ADDRENV each task's
stack lives behind its own page tables mapped at the same fixed
virtual range, so reading tcb->stack_base_ptr without first switching
to that task's addrenv reads whatever physical page the caller's own
mapping of that virtual range happens to point to, not the target
task's real stack. A cross-tid dumpstack of a task running in a
different address environment therefore returns garbage or an
all-zero backtrace instead of failing cleanly or resolving the real
call chain.
Add an addrenv parameter to backtrace() and select the target tcb's
addrenv_own only around the two dereferences that read the target's
saved ra/fp (ra = *(fp - 1), next_fp = *(fp - 2)), then restore the
caller's own addrenv before writing the result into buffer. buffer
belongs to the caller, not the target tcb, so it must always be
written back in the caller's own address environment; writing it
while the target's addrenv is still selected would corrupt the
access instead of fixing it.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
xcp.ustkptr is only assigned once in up_initial_state() when a task is
created and, since the syscall fast path was optimized in
e6973c764c, is never updated afterwards. up_backtrace() used
"ustkptr != NULL" to decide whether a task is currently blocked
inside a syscall, and *(ustkptr + 1) as the frame pointer to resume
tracing from. Since ustkptr is now a dead value fixed at task
creation time, the check is always true and the "frame pointer" it
derives points at stale data near the initial stack top, unrelated
to where the task is actually blocked.
Use rtcb->flags & TCB_FLAG_SYSCALL together with xcp.sregs, which
dispatch_syscall() maintains precisely across the entire syscall
execution window (including any nested context switches caused by
blocking), to locate the frame pointer/return address saved at
syscall entry instead.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
host_flags_to_mode() used a trailing 0 entry in modeflags[] as the
loop-termination sentinel. O_RDONLY is defined as 0 and is exactly
modeflags[1], so the loop's termination check fired before ever
comparing that entry, and a bare O_RDONLY open always fell through
to -EINVAL.
Bound the loop by array size (nitems()) instead of a value sentinel.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Propagate the solution for SD card bugs to the nxinit configuration,
which also uses the nxinit configuration.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Updated the documentation to reflect the fix of buggy SD card behaviour
at the sacrifice of slower performance.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
I document the issues encountered with multi-block transfers, namely the
block count failing to be set correctly. Even though I did test with
that issue corrected, it required modifications to the upper-half MMCSD
driver which I am not prepared to test. It also did not fix the time-out
on multi-block transfers, likely because the method of verifying FIFOs
have space to write is finicky. For now, limiting the block count of
transfers resolves the bug!
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Cache must be invalidated before the buffer is read since the
VideoCore's write will not invalidate the cache.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Summary
Permissions (Part 3)
Description:
In kernel builds, any unprivileged process running on the NuttX device can
open /dev/efuse and attempt to read/write fuse content. Reading the fuses
may provide valuable information to an attacker controlling the user process.
The write operation, in extreme cases where the fuse blocks are not locked,
may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
Impact
See https://github.com/apache/nuttx/issues/19410
Testing
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Permissions (Part 2)
Description:
In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Description:
In kernel builds, any unprivileged process running on the NuttX device
can open /dev/efuse and attempt to read/write fuse content. Reading the
fuses may provide valuable information to an attacker controlling the user
process. The write operation, in extreme cases where the fuse blocks are
not locked, may brick the device.
This is part of https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Fix security issue where uninitialized kernel stack contents could be
leaked to userspace when mfrc522_picc_select() fails.
In mfrc522_read(), the local variable 'uid' was not initialized before
being passed to mfrc522_picc_select(). If the function fails (e.g., due
to bad data on the SPI bus), the uninitialized uid.sak value could pass
the PICC_TYPE_NOT_COMPLETE check, causing snprintf() to copy
uninitialized kernel stack data to the userspace buffer.
Fixes#19417
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
Author: hanzhijian <hanzhijian@zepp.com>
Explain how drivertest applications are selected and run, list the current test categories, and document the watchdog reset and notifier test behavior.
Assisted-by: OpenAI Codex
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
Provide per-instance capture automonitor lookup for watchdog lower halves
that pass callback context, and avoid selecting an unrelated watchdog when
legacy lower halves provide no context. Update STM32 WWDG lower halves to pass
their instance context so multiple watchdog devices remain distinguishable.
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
Assisted-by: OpenAI Codex
The group address in the IGMP header is declared as uint16_t grpaddr[2],
so it decays to a pointer. Comparing it against INADDR_ANY compares the
address of a struct member against 0, which is always false. The General
Query branch is therefore unreachable and GCC discards it entirely.
Commit 09bb292fa2 ("net/igmp: fix build warning on GCC 12.2.0") replaced
the original
if (igmp->grpaddr == 0)
with
if (net_ipv4addr_cmp(igmp->grpaddr, INADDR_ANY) != 0)
but net_ipv4addr_cmp(a, b) expands to (a == b) and INADDR_ANY expands to
((in_addr_t)0), so the emitted comparison is unchanged. The -Waddress
diagnostic disappeared only because the comparison now originates inside
a macro expanded from a header included via -isystem, and GCC suppresses
warnings from system-header macros. The defect was hidden, not fixed.
That commit also rewrote the unicast query test from group->grpaddr != 0,
which was well-formed, into the same pointer comparison, making it
unconditionally true.
Convert the header field with net_ip4addr_conv32() once, and compare the
resulting in_addr_t. The conversion was already being done in the
group-specific branch, so this only hoists it and reuses it.
Impact: a General Query (destination 224.0.0.1, group address 0) is the
periodic query every IGMP querier sends. It currently falls through to
the group-specific branch, where igmp_grpallocfind() allocates a group
for 0.0.0.0 and schedules a report for it, while joined groups never have
their report timers restarted. The querier then ages out the membership
and multicast delivery to the device stops.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The board-common stm32_reset.c and stm32_romfs_initialize.c are already
provided by boards/arm/common/stm32. Remove the redundant local copies
from boards
Signed-off-by: raiden00pl <raiden00@railab.me>
Fix two latent defects in the W5500 Ethernet driver:
1. NETDEV_RXERRORS() references non-existent variables (line 1351):
In w5500_receive(), the error path uses &priv->dev but the function
parameter is named self and the device field is w_dev. This compiles
only because NETDEV_RXERRORS() expands to nothing without
CONFIG_NETDEV_STATISTICS; enabling statistics breaks the build.
2. d_private set to the device array instead of the instance (line 2069):
In w5500_initialize(), d_private was set to g_w5500 (the global array)
instead of self (the current instance). This is harmless for device 0
(g_w5500 == &g_w5500[0]) but wrong for any devno > 0 — every callback
that recovers the driver state via dev->d_private would operate on
device 0's state.
Fixes#19306
Signed-off-by: hanzhijian <hanzhijian@zepp.com>
Author: hanzhijian <hanzhijian@zepp.com>
ice40_endwrite() computes how many dummy SPI bytes to clock out after
the bitstream to finish FPGA configuration with:
for (size_t i = 0; i < ICE40_SPI_FINAL_CLK_CYCLES + 7 / 8; i++)
`/` binds tighter than `+` in C, so this parses as
ICE40_SPI_FINAL_CLK_CYCLES + (7 / 8) = 160 + 0 = 160, i.e. the "+ 7 / 8"
is a silent no-op. The macro name and the classic `(n + 7) / 8`
ceiling-division idiom (used elsewhere in embedded code to convert a
bit/cycle count into a byte count) make clear the intent was to send
ceil(ICE40_SPI_FINAL_CLK_CYCLES / 8) = 20 bytes (160 SPI clock cycles,
matching the macro name). Instead the unmodified code sends 160 bytes,
i.e. 1280 clock cycles - 8x more than intended.
Fix by parenthesizing the ceiling-division: (ICE40_SPI_FINAL_CLK_CYCLES
+ 7) / 8, which evaluates to 20, restoring the intended 160-clock-cycle
finalization sequence.
Fixes#19367
Assisted-by: Claude Code:claude-sonnet-5
Signed-off-by: yi chen <94xhn1@gmail.com>
Reading /proc/<pid>/group/env for another task dereferenced tg_envp
under the caller's own address environment instead of the target
task's, since tg_envp lives in the target's user heap. Switch to the
target's address environment around the traversal, and to the
caller's own environment only around the copy into the caller's
buffer.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
uart_putxmitchar() manipulates dev->xmit.head/buffer directly with
no internal locking - every other caller (uart_write()) takes
dev->xmit.lock first. uart_readv()'s ECHO handling (both the
backspace/delete erase sequence and the normal character echo)
calls uart_putxmitchar() without taking that lock, so a concurrent
uart_write() and a local echo can race on the same circular buffer
state, corrupting it.
Take dev->xmit.lock around each echo's uart_putxmitchar() calls,
matching what uart_write() already does. uart_readv() holds
dev->recv.lock for its own duration, but no other code path ever
acquires recv.lock while holding xmit.lock, so nesting xmit.lock
inside the existing recv.lock scope here doesn't introduce a new
lock-ordering cycle.
Fixes#14845
Signed-off-by: yi chen <94xhn1@gmail.com>
stm32h5/stm32_i2c.c selected the I2C2/3/4 kernel clock with
RCC_CCIPR4_I2CnSEL_PCLKx, but the H5 RCC header names those values
RCC_CCIPR4_I2CnSEL_RCCPCLKx.
Signed-off-by: raiden00pl <raiden00@railab.me>
This board config is reaching the 64KB Flash limit, so disable some
not used interface to reduce size.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
There was another small issue on sixlowpan_input.c code, it was
processing protosize and 8-bit instead of 16-bit.
It was working because the max tcp->tcpoffset was 0xf0, so
protosize = ((uint16_t)tcp->tcpoffset >> 4) << 2;
Will be protosize = 15 * 4 = 60 and will fit inside 8-bit.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
This commit checks if the incoming 6LoWPAN frame header len + the
IPv6_HDRLEN will fit inside the b->io_len.
Signed-off-by: Alan C. Assis <acassis@gmail.com>
