Initialize i2c_ll_hw_cmd_t in sendstart/startrecv so ack_exp/done are
not left with stack garbage that can NACK or skip the address byte.
Program i2c_hal_set_bus_timing() with the requested bus_freq instead of
the board default so msg frequency is applied.
Affects only Espressif devices.
Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
The 32 MHz TCXO that clocks the SX1276 is powered from PA12 and was never
driven, so the radio had no clock at all. The user button was copied from
the Nucleo L073RZ and left on PC13, which carries DIO3 of the radio on this
board; it is PB2.
Adds lorawan_tx and lorawan_beacon, with the radio defaults of a public
LoRaWAN network in the 915 MHz band, and fills in the board page.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
- The frequency step was truncated to 61 Hz, while it is FXOSC/(2**19),
about 61.035 Hz. The error puts a 915 MHz channel more than 500 kHz away
from the requested frequency, outside its own bandwidth.
- The low or high frequency front end was left at its reset value, so a board
wired for 868 or 915 MHz neither transmitted nor received.
- sx127x_rx_watchdog() is only used by the FSK and OOK path but was compiled
whenever receive support was on, so a LoRa only configuration failed to
build with -Werror. nrf52840-dk:sx127x is such a configuration.
Adds the sync word, the default bandwidth and the default spreading factor as
configuration options, all defaulting to the previous behaviour, and a page
for the driver under components/drivers.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Character driver for the Semtech SX1301, the baseband processor of a LoRaWAN
gateway, and the two SX125x radios it drives. Received packets come from
read(), downlinks go to write(), and the channel plan, the start and the stop
are ioctls.
The interface is device independent, in nuttx/wireless/lpwan/lora_gw.h with
the commands in the common WLIOC_GW_* space, so another concentrator driver
can implement it and the same application drive it.
Adds a lorawan_gw configuration for the Nucleo F746ZG with a shield of the
LRWAN_GS_HF1 family. Off by default (LPWAN_SX1301).
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
STM32_STM32L0 does not select STM32_HAVE_SYSCFG, so STM32_SYSCFG does not
exist for this family and the clock of the peripheral is never enabled. The
mapping of a pin to an EXTI line lives in SYSCFG_EXTICR, so every write to it
was dropped and a GPIO interrupt on any port other than port A never fired.
STM32_SYSCFG is default y, so no configuration changes.
Assisted-by: Claude Code 4.8
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
Allow zero-length I2C transfers when DEBUGASSERT is enabled.
Zero-length transfers (used for I2C bus scanning) never access the
transfer buffer, so any EasyDMA pointer is valid.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
stm32_i2c_init() and stm32_i2c_deinit() hardcoded APB1LENR/APB1LRSTR
while taking the enable and reset bits from the per-instance config.
That is correct for I2C1-3, but I2C4 is on APB4: its clk_bit and
reset_bit are RCC_APB4ENR_I2C4EN and RCC_APB4RSTR_I2C4RST, both bit 7,
and bit 7 of APB1LENR/APB1LRSTR is TIM13.
So for I2C4 the driver enabled and pulsed the reset of TIM13 instead,
and never reset the I2C4 peripheral at all. I2C4 still works because
rcc_enableapb4() enables I2C4EN at boot, but the peripheral reset that
stm32_i2c_reset() (CONFIG_I2C_RESET) relies on to clear a wedged I2C
state machine never happens, and deinit gates TIM13 while leaving the
I2C4 clock running.
Store the clock enable and reset register addresses in
struct stm32_i2c_config_s next to the bits, and use them in
stm32_i2c_init() and stm32_i2c_deinit().
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The CMake build referenced arm64_physpgaddr.c and arm64_virtpgaddr.c,
which no longer exist (consolidated into arm64_pgalloc.c, already
listed).
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
igmp_input() verified the packet length with:
if (dev->d_len < NET_LL_HDRLEN(dev) + (iphdrlen + IGMP_HDRLEN))
but dev->d_len at this point holds the IPv4 total length (IP header plus
payload) without the link-layer header, consistent with the convention
established in ipv4_in()/ipv6_in() (which do `dev->d_len -=
NET_LL_HDRLEN(dev)`) and used by all other transport input handlers
(icmp, tcp, udp), none of which reference NET_LL_HDRLEN.
Adding NET_LL_HDRLEN(dev) to the right-hand side made the check always
true for valid IGMP packets:
iphdrlen + IGMP_HDRLEN < NET_LL_HDRLEN + iphdrlen + IGMP_HDRLEN
(= 0 < NET_LL_HDRLEN)
so every well-formed IGMP message hit the "Length error" path and was
silently dropped, breaking IGMP membership query/report processing.
Drop the extra NET_LL_HDRLEN(dev) so the check matches the other
protocol handlers.
Signed-off-by: zhekunren <zhekunren@qq.com>
Adds documentation to input and touchscreen controller files, regarding
support for ST7123 IC.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Add support for ST7123 touchscreen controller (I2C only).
It requires board level init to register a callback, as polling
mode is not supported.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
Add support for the Microchip 24CW160 (2048B, 32-byte pages, 2-byte
data address)
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The CMake build had no STARTUP_OBJS (crt0) target and no elf.cmake, so
applications were linked without crt0 and without '-e _start': the ELF
entry defaulted to main and applications crashed on exit returning to
a NULL address.
Add STARTUP_OBJS and elf.cmake with the LDELFFLAGS equivalents from
Toolchain.defs, following the other architectures.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Use CONFIG_STM32_UART8_SERIALDRIVER so g_uart8rxbuffer and
g_uart8txbuffer are compiled when UART8 is enabled.
Signed-off-by: Joao Mario Lago <joao.mario.lago@hotmail.com>
The CMake build does not need the manual export/import/mkromfsimg
steps: applications and the ROMFS image are generated by the normal
build. Document the CMake invocation and how to run the image.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The CMake build compiled no ROMFS source, so kernel-mode
configurations (knsh_romfs) failed to link with undefined references
to romfs_img. Generate the ROMFS image from the applications in
<build>/bin with genromfs/xxd and compile it into the board library;
other configurations keep the empty stub.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Match the Application.mk install rule: keep the application attribute
symbols (nx_stacksize etc.) through strip as NX_KEEP does, and mark
the installed binaries executable, since ld -r output is not and
filesystem images built from bin/ refuse to exec.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
CMAKE_LD was never set, so application link commands were invalid, and
CMAKE_STRIP defaulted to plain 'strip', which removes the symbol and
relocation tables required to load CONFIG_BINFMT_ELF_RELOCATABLE
binaries. Use the host linker and 'strip --strip-unneeded' as on the
other architectures.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
arch_interface exists only for CONFIG_BUILD_PROTECTED, but x86_64 and
arm64 referenced it for any non-flat build, breaking CMake
configuration of kernel builds. Use the CONFIG_BUILD_PROTECTED guard
as arm and risc-v do.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
mknxflat is built from tools/nxflat by the NuttX build itself, so the
toolchain section no longer sends the reader to buildroot for it; only
ldnxflat still comes from there. Bring the mknxflat usage text in line
with the tool, note that MKNXFLAT and LDNXFLAT are supplied by the ARM
Toolchain.defs, and correct the r10 references left in the PIC
descriptions.
Describe the module ABI marker, so that a user whose prebuilt module
starts failing exec() with ENOEXEC finds out that the loader refuses a
module whose import table does not name __nxflat_abi_v2, and that
rebuilding the module is the fix.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
ARM PIC has used r10 as the base register, but the tree has never been
consistent about it. Toolchain.defs gives CONFIG_BUILD_PIC
-mpic-register=r9 and CONFIG_PIC -mpic-register=r10, twenty-five lines
apart, and arm_initialstate.c sets REG_R9 from inline assembly under one
and REG_PIC under the other, with a comment reading "Set the PIC base
register (probably R10)". This settles it on r9 for all of PIC: NXFLAT,
ELF PIC and CONFIG_BUILD_PIC alike.
r9 is the right choice rather than an arbitrary one. It is the AAPCS
platform register, the "static base", and it is what GCC itself picks
for -msingle-pic-base on an EABI target; r10 is the non-EABI default.
It also removes a combination that cannot build today. Stack checking
adds -ffixed-r10 in armv7-m/Toolchain.defs and armv8-m/Toolchain.defs,
while CONFIG_PIC adds -mpic-register=r10, and GCC rejects the pair with
"unable to use 'r10' for PIC register". The comment above REG_PIC has
always said the register "can be R9 if stack checking is enabled", but
the definition was unconditionally REG_R10, so it would have named the
wrong register even had the build succeeded.
The thunk generator moves with the firmware. NXFLAT import stubs had
the register baked in as "add ip,ip,sl", so a module built for r9 would
load and then branch to a wild address on its first call out. The stubs
now come from NXFLAT_PIC_REG in the in-tree tool, which is built only
when CONFIG_NXFLAT is set, following the
CONFIG_BOARD_ETC_ROMFS_PASSWD_ENABLE precedent in tools/Unix.mk.
That leaves modules built before this change, and they are the reason
for the ABI marker. The NXFLAT header cannot carry a version: h_magic
is written by ldnxflat, which is GPL, derived from elf2flt, and stays
out of this repository, so it can never be changed in step with the
loader. The import table can, because both of its ends are in-tree --
mknxflat emits it and nxflat_bindimports() reads it -- and ldnxflat
passes it through untouched. So every module now imports
__nxflat_abi_v2, the base firmware defines it, and a module that does
not import it is refused.
Making the marker a real exported symbol rather than a name the loader
special-cases is what keeps it out of the build system's way: a board's
symbol table picks it up exactly as it picks up printf, so mksymtab.sh
and its equivalents need no change. It also gives the reverse direction
a diagnosis for free -- a module built against a newer ABI than its
firmware fails with "Exported symbol __nxflat_abi_v2 not found".
Most of the remaining churn is boards restating a default. ARCHPICFLAGS
is a "?=" default so that a board only speaks up when it differs, and
twenty-six were assigning the value the default already had. MKNXFLAT
gets the same treatment: thirteen boards named the same tool, and the
only thing that varies is ARM versus Thumb-2, which falls out of
CONFIG_ARM_THUMB. LDNXFLAT gains a default too -- it stays an
out-of-tree PATH lookup, but naming it centrally fixes boards that never
assigned it, where it expanded to nothing and handed make a recipe
beginning "-e", whose leading dash make ate as "ignore errors".
The non-ARM boards carrying -mpic-register=r10 lose it: it is an
ARM-only option, reachable only through CPICFLAGS, which is only used to
build NXFLAT modules, and no non-ARM board enables NXFLAT.
Boards keep nothing about PIC flags any more. ARCHPICFLAGS was set by
sixty-three of them and only ever fed CPICFLAGS, which is only used to
build NXFLAT modules; no board outside arch/arm enables NXFLAT, so every
non-ARM copy was setting a variable nothing read. Those are removed
rather than moved somewhere more central, which would only make dead
text look load-bearing. LDNXFLAT goes the same way as MKNXFLAT, for the
same reason: thirteen boards named the same tool that Toolchain.defs now
names once.
One of them was not merely redundant. am67/t3-gem-o1 asked for
"-mpic-register=r10 -ffixed-r10", which GCC refuses outright with
"unable to use 'r10' for PIC register" -- the very combination the
filter-out machinery in Toolchain.defs exists to prevent. It has
survived because that board does not build NXFLAT modules, so the flags
are never handed to a compiler. Renaming the register would have
carried the fault forward unchanged, so the line goes.
Tested on lm3s6965-ek:qemu-nxflat under QEMU, configured and built with
no overrides. The nxflat example runs the errno, hello and struct
modules with output identical to the same config built from master.
Built with the old out-of-tree thunk generator instead, the same
firmware refuses all three with ENOEXEC rather than locking up in a
HardFault, which is what this change is for. mps3-an547:picostest,
which is CONFIG_PIC without CONFIG_NXFLAT, builds clean and does not
build the thunk generator.
The .def files pick up two cosmetic changes here alongside the register:
a "Dyanamic" typo that codespell rejects, and a reworded comment in each
thunk_*.c. Neither appears in the emitted thunk -- both are in C
comments -- so the generated text is still what the upstream tool
produces, modulo the register itself.
BREAKING CHANGE: ARM PIC moves from r10 to r9. An NXFLAT module built
before this change has r10 baked into its import stubs and will not run
against a firmware carrying it; the two cannot be mixed. The module is
refused with ENOEXEC rather than branching to a wild address, by way of the
__nxflat_abi_v2 marker described below.
Quick fix: rebuild the module against this tree. Its source needs no
change. A board that reserved r10 by hand, or that assigned ARCHPICFLAGS
or MKNXFLAT to restate a default, should drop those assignments; nothing
else is affected, and CONFIG_PIC without CONFIG_NXFLAT needs no action.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
The tool arrived from the buildroot NXFLAT toolchain under BSD-3-Clause,
jointly copyright Gregory Nutt and Cadenux, LLC. Gregory Nutt owned
Cadenux and was its only developer on this code, and has agreed to the
conversion, so the six files take the ASF header like the rest of the
NuttX code he donated. Copyright attribution moves to NOTICE, which is
where the donation put it for everything else of his in the tree.
This covers only what was imported: mknxflat and the thunk skeletons it
emits from. ldnxflat is the file with an elf2flt lineage, and it is not
here -- it stays out of tree in buildroot, and NuttX keeps calling it as
an external tool.
The .def files also gain their in-tree path on the first line, which the
import had left pointing at the buildroot layout.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
An NXFLAT module reaches the base firmware through a "thunk" file: one
assembly stub per imported function, generated by mknxflat. That tool
has always lived outside this repository, in the NuttX buildroot NXFLAT
toolchain, so building an NXFLAT module needs a separate checkout and a
separate build of a tool that links against libbfd.
libbfd is why it stayed out. It is GPL, which an Apache project cannot
depend on, and it is awkward to obtain besides -- a stock binutils
install often ships libbfd without the libiberty it needs to link. But
the dependency was never deep. mknxflat used libbfd for eight calls,
all of them opening the file and walking the symbol table; it never
relocates or rewrites anything. That is replaced here by reading the
ELF symbol table directly, which removes the dependency outright and
costs about a hundred lines.
The emitted text is unchanged. The format strings live in the .def
files, which are carried here byte-for-byte from upstream, and the
selection rule for what becomes a thunk is the upstream one: everything
undefined that is not explicitly an object. Symbol typing cannot be
trusted for this -- imported functions are routinely emitted as
STT_NOTYPE rather than STT_FUNC, while a weakly defined object does
appear as an undefined object -- so the test is on what a symbol is not.
Upstream chose the instruction set at compile time through an "arch"
symlink pointing at either arm/ or thumb2/. A symlink cannot be carried
in the repository, and one host binary has to serve boards of both
flavours, since lpc31xx is ARM while lpc17xx, tiva, stm32f1 and rp23xx
are Thumb-2. That choice becomes a runtime "-a" option. The "-f"
option, which read further command line arguments from a file, is
dropped; nothing in the tree used it.
This commit changes no output. Against the upstream tool, for both
architectures, with and without -w, over modules exercising the plain,
weak and non-returning thunk paths, the generated thunk files are
byte-identical.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Include STM32_HAVE_USART_H5 in the UART7/UART8 driver choice
depends so CONFIG_STM32_UART*_SERIALDRIVER can be selected on
STM32H5.
Signed-off-by: Joao Mario Lago <joao.mario.lago@hotmail.com>
g_rtc_lock is used by the up_rtc_settime, a base RTC function.
Therefore, it should be available even for this procedure, not just when
CONFIG_RTC_HIRES.
Signed-off-by: Jiri Vlasak <jvlasak@elektroline.cz>
Several risc-v assembly labels are .global but untyped, so mkallsyms.py
(which only collects STT_FUNC symbols) silently drops them from the
ALLSYMS table, and backtraces/%pS print raw addresses instead of names.
Add .type <name>, function to the affected labels, matching existing
convention elsewhere in the tree.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Assisted-by: Claude Code:claude-sonnet-5
allsyms_lookup() derived a symbol's size from the physically next table
entry, assuming address order. Under CONFIG_SYMTAB_ORDEREDBYNAME the
table is sorted by name instead, producing a huge bogus size in
%pS/backtrace output.
Scan for the closest larger address instead of relying on table order.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Assisted-by: Claude Code:claude-sonnet-5
allsyms_findbyvalue()/%pS printed a bogus name/offset for addresses
outside the real symbol table's coverage, due to the boundary sentinels
being matchable as real symbols.
Compute the high sentinel from the actual symbol range and treat a
sentinel match as "not found".
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Assisted-by: Claude Code:claude-sonnet-5
g_allsyms/g_nallsyms only exist in the kernel image, but symtab_allsyms.c
is unconditionally built into libc.a, so user-mode code under
CONFIG_BUILD_PROTECTED/CONFIG_BUILD_KERNEL fails to link.
Guard the affected code so user-mode libc.a no longer references these
kernel-only symbols.
Signed-off-by: liang.huang <liang.huang@houmo.ai>
Assisted-by: Claude Code:claude-sonnet-5
When a running task changes its affinity on SMP and is no longer eligible to run on the current CPU, merely delivering an equal-priority scheduling request can leave the task in g_readytorun while the target CPU remains idle. The task then never runs again.
Remove the task from its current CPU, add it back to the ready-to-run list so a suitable CPU is selected, and perform the context switch unconditionally. This ensures the task is migrated according to its updated affinity.
Fixes: https://github.com/apache/nuttx/issues/19680
Assisted-by: GitHub Copilot:ppio/pa/gpt-5.6-sol
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Two level errors corrupted kernel memory when a user process extended
its heap with sbrk:
- PGT_LAST was X86_MMU_PT_LEVELS (4), but valid levels are 0-3, so the
final level entry was written with an out-of-range index.
- x86_64_get_pgtable indexed the PD (level 2) with level 3, installing
newly allocated page tables into the wrong PD slot.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
A fetch() only lower half is always ready, so a subscriber that asked for
a rate with SNIOC_SET_INTERVAL got no pacing from poll(): the descriptor
reported POLLIN on every pass and the application had to sleep out the
period itself. That does not compose. An application polling several
topics reads them sequentially from one thread, so per read sleeps
serialize: three topics at 10 Hz sleeping 100 ms each yield 3.3 Hz per
topic rather than 10.
Pace it where poll() can act on it instead. A subscriber that never
requested a rate stays always ready, and one that did becomes ready once
per its own interval, driven by a watchdog armed in sensor_poll(). This
is the fetch() side of what sensor_is_updated() already does for a
pushing lower half, so both models now honor a requested rate the same
way.
The wdog_s lives in sensor_user_s rather than in the device, so each
subscriber is paced at its own interval instead of at the minimum across
all of them, and the timer only runs while somebody is polling. The
expiry runs in timer context and takes no lock: poll_notify() is safe
from an interrupt handler, and a teardown that raced it has already
cleared fds, which makes both the notify and the re-arm no-ops. Teardown
therefore just cancels the watchdog where it clears fds, and a watchdog
keeps this off the work queue entirely, which a fetch() only sensor
exists to avoid.
sensor_close() needs nothing of its own: poll_setup() holds a reference
on the file for the duration of the poll, so file_close() cannot run
until poll_teardown() has called sensor_poll() with setup false, and that
already cancelled the watchdog.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
A fetch() only lower half reads the device on demand, so its data is
always available and there is never anything to wait for. The upper half
did not reflect that: poll() only reported POLLIN when the descriptor was
opened O_NONBLOCK, and a blocking read() waited on buffersem, which is
only posted when the lower half drives notify_event from an interrupt of
its own.
A fetch() only sensor with no interrupt therefore never satisfied
poll()/read() at all. This is not hypothetical: in the in tree
nucleo-h563zi:dts configuration CONFIG_STM32_DTS_TRIGGER defaults to 0,
which selects stm32_dts_fetch(), and no CONFIG_STM32_DTS_ITEN_* option is
enabled, so the DTS interrupt never fires. A blocking read() on that
sensor waits forever, even though stm32_dts_fetch() performs a complete
software triggered measurement on its own and needs no interrupt at all.
Applications had to work around this by forcing O_NONBLOCK on the
descriptor themselves, see apache/nuttx-apps#3686.
Drop the O_NONBLOCK special case in both paths: sensor_poll() now always
reports POLLIN for a fetch only sensor and sensor_read() calls fetch()
directly instead of waiting. Update the sensor_ops_s::fetch
documentation, which described the old contract.
With the wait gone, buffersem has no waiters left. Its only two readers
were the ones removed here, both in the fetch path: the wait in
sensor_read() and the nxsem_get_value() in sensor_poll(). The remaining
nxsem_post() calls in sensor_push_event() and sensor_notify_event() had
nothing left to wake, so drop the semaphore and those posts as well.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The driver had two modes selected by CONFIG_SENSORS_L3GD20_BUFFER_SIZE:
with a buffer it pushed samples from a work queue, and without one it
exposed fetch() while still using the data ready interrupt to signal
readiness through notify_event.
That second mode misuses the fetch interface. fetch() means the data is
read from the device on demand and is therefore always available, while
an interrupt driven sensor is exactly what push_event is for. Mixing the
two forces the upper half to guess whether a fetch() only lower half
will ever notify, and it makes poll() unusable in a multi descriptor
loop, because the descriptor reports ready while the read still has to
wait for the next interrupt.
Drop the fetch path and always use the work queue and push_event, which
is what the driver already did by default since BUFFER_SIZE defaults to
1. CONFIG_SENSORS_L3GD20_BUFFER_SIZE gains a range of 1 to 32, as a zero
sized buffer no longer has a meaning, and SCHED_HPWORK is now selected
unconditionally because the work queue is always used.
No in tree configuration enables this driver and the previous default
already took the push path, so no defconfig changes are needed.
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
The condition work_available(&conn->work) && tx_unacked != 0
prevented tcp_update_retrantimer from being called when the work
queue was still busy, leaving conn->timer stale or zero on
subsequent sends. This caused the RTT estimation to compute a
false RTT (m = rto - 0 = rto), creating a positive feedback loop
that inflated the RTO to extreme values (e.g., 232 half-seconds
= ~116 seconds).
Fix: remove the work_available check so that tcp_update_retrantimer
is always called when there is unacknowledged data. The decision to
re-queue the work is handled internally by tcp_update_timer.
Signed-off-by: zhekunren <zhekunren@qq.com>
The audio subsystem page listed the source files and the configuration
options, but nothing about the interface the upper half presents to
applications. PR #18348 added a device state machine, a second buffer
allocation mode, poll and mmap support and several new ioctls, none of
which were described anywhere, so the only way to learn the expected
call sequence was to read audio/audio.c.
Document what the upper half now guarantees:
- the device state machine, and the fact that AUDIOIOC_START is
rejected until AUDIOIOC_CONFIGURE has moved the device out of
AUDIO_STATE_OPEN;
- the normal open/configure/allocate/enqueue/start sequence;
- the two AUDIOIOC_ALLOCBUFFER modes selected by u.pbuffer, who owns
the buffers in each, and that a shared ring request may return zero
when the ring is already populated;
- that AUDIOIOC_GETBUFFERINFO also establishes the shared ring depth,
so a lower half which does not implement it disables that mode;
- the poll event semantics and how mmap() selects between a ring
buffer and the device status by requested length;
- all ioctls handled by the upper half, grouped by purpose;
- how per-open state is aggregated into the device state when several
applications share one device.
No functional change.
Signed-off-by: fangyibo <fangyibo@xiaomi.com>
The upper->periods >= upper->nbuffers check sat at the top of
audio_allocbuffer(), but upper->periods is only incremented for shared
ring requests (u.pbuffer == NULL), so for private buffer callers the
check degenerated into "nbuffers == 0" and rejected every allocation
when the lower half does not implement AUDIOIOC_GETBUFFERINFO, which is
the only place nbuffers is ever assigned.
Move the guard inside the shared ring branch so private buffers, which
never enter upper->apbs[] and are unrelated to the ring depth, stay
allocatable. The zero return value is kept as-is because a second
application attaching to the same device relies on it to skip
allocation and go straight to AUDIOIOC_ENQUEUEBUFFER.
Signed-off-by: fangyibo <fangyibo@xiaomi.com>
RGBTO8 shifted each component up before masking:
(((uint8_t)(r) << 5) & 0xe0)
The cast is promoted to int before the shift, so the mask keeps bits 5:7
of the shifted value, which are bits 0:2 of r. The macro therefore
encoded the three least significant bits of red and green and the two
least significant bits of blue, rather than the most significant.
This disagrees with RGBTO16 in the same file, which correctly takes the
high bits, and with RGB8RED/RGB8GREEN/RGB8BLUE immediately below it,
which are documented as the inverse transformation but read the result
as high bits.
All in-tree callers pass full 8-bit components, so all were affected:
RGBTO8(39, 64, 139) in apps/examples/nxterm, intended as midnight blue,
evaluates to 0xe3 -- full red plus full blue, i.e. magenta.
Take the high bits instead, so that RGBTO8 matches RGBTO16 and the
RGB8xxx macros become its true inverse.
Tested on a RISC-V LiteX/VexRiscv target with an 8bpp RGB332 frame
buffer, and with a host round-trip check over all 256 representable
colours.
Assisted-by: Claude:claude-opus-5
Signed-off-by: William Byatt <william@byatt.io>
The registration example showed the three argument form, which no longer
compiles, and fetch() as the only way samples are taken. Update it, add
a section on the two acquisition modes and the attach() a board provides
for the interrupt one, and state the 100 Hz sample rate.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
fetch() timestamps a sample when the application asks for it, not when
the device measured it, and reads accel and gyro separately so the two
topics never share an instant. Add an optional push mode behind
CONFIG_SENSORS_MPU6050_INT: the board supplies mpu6050_config_s::attach,
the handler timestamps and defers to HPWORK, and the worker reads once
and pushes both topics. The I2C read cannot run in the interrupt.
The mode is chosen at build time, so fetch() is simply left out of the
ops table and out of the build when the option is set: an instance uses
one model or the other, never the mixture that made poll() unusable on
l3gd20. A board that enables it without attach fails with -EINVAL.
Also set CONFIG so the DLPF is on. Left at reset the gyroscope output is
8 kHz, not 1 kHz, so SMPLRT_DIV 9 gave 800 Hz rather than the documented
100 Hz; measured 833 Hz before and 101 Hz after. fetch() hid this since
the application set the pace.
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
RNDIS reports Ethernet packet sizing to the host through NDIS OIDs.
OID_GEN_MAXIMUM_FRAME_SIZE is the MTU-style value and excludes the
link-layer header, while CONFIG_NET_ETH_PKTSIZE includes the Ethernet
header.
Report the frame size as CONFIG_NET_ETH_PKTSIZE - ETH_HDRLEN, and
report OID_GEN_MAXIMUM_TOTAL_SIZE as CONFIG_NET_ETH_PKTSIZE instead of
a hardcoded 2048.
Assisted-by: OpenAI Codex:GPT-5
Signed-off-by: shichunma <shichunma@bestechnic.com>
The documentation job installs with `pipenv install`, which does not honour
the committed Pipfile.lock. Every run in the logs prints "Locking
dependencies..." and "Updated Pipfile.lock" and then installs from the set it
has just re-resolved, so each build takes whatever PyPI resolves that day
rather than what the lock file names.
On the evening of 2026-08-03 that resolution produced a virtualenv without
packaging, and four unrelated pull requests failed identically, before Sphinx
had read a single file:
File ".../sphinx/extension.py", line 7, in <module>
from packaging.version import InvalidVersion, Version
ModuleNotFoundError: No module named 'packaging'
`pipenv sync` installs exactly what Pipfile.lock names and never re-resolves,
which is what the lock file is for. The committed lock covers all fourteen
packages the Pipfile asks for, packaging included, so it is complete enough to
install from as it stands.
The workflow also ran only for changes under Documentation/, so a change to the
documentation build was never exercised by the build it changed. It now
triggers on its own path as well, which is what tests this commit.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Adds LDO support for RISC-V Espressif devices. In general, should
only affect ESP32-P4 on a few boards.
ESP32-P4 has 4 channels of low-dropout voltage regulators, which
are programmable. Can be used to power external devices.
Signed-off-by: Filipe Cavalcanti <filipe.cavalcanti@espressif.com>
- Zero initialize union in s32k3xx_transmit()
- Allow setting BRS from frame flags
Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Zero initialize union in s32k1xx_transmit()
- Allow setting BRS from frame flags
Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Zero initialize union in kinetis_transmit()
- Allow setting BRS from frame flags
Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Zero initialize union in imx9_transmit()
- Allow setting BRS from frame flags
Signed-off-by: Takashi Furuya <takashi.furuya@nttedt.co.jp>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
