Hello - I tested PR 21366 and I can confirm that the ws2812 example
application works correctly with the diff applied and byte order
transformation active. Also tested with/without the bounds check and
confirmed that the check does prevent buffer overrun and memory
corruption.
As for the PR itself - I think the fix in ws2812_read can be shortened
to just calling ws2812_byte_order_transform_rgb with res >> 2 instead
of
len >> 2 and that the call to ws2812_byte_order_len isn't needed here.
The reason is that the lower half read handler will reduce len in the
same manner as ws2812_byte_order_len does it and res will therefore be
bound to len.
(Calling ws2812_byte_order_len does not break anything here but it
looks
like a bug because it is skipped in some configurations/code paths. It
can also make someone think that the upper half is supposed to take
care
of bounding the len parameter which is currently not the case, lower
halves are doing it.)
On 2026-11-02 20:24, [email protected] wrote:
> First of all - big thanks to you and to everyone involved in helping
> getting all of this merged and for all the fixes. And once again, sorry
> for the mixup with the dev branch.
>
> I compared the code that was supposed to be merged with the code that
> is currently in the mainline and it looks like there is only a minor
> difference, two function description templates left from the header
> file template in the coding style document. I prepared one more patch
> series that removes those templates and also removes description of the
> configuration option that was not added to WS2812 upper half Kconfig.
> The branch is named "doc_cleanups"
>
> As for the PR 21366, I can test it on hardware tomorrow, will also
> check if the merged code was the final version.
>
> Other than that, I have a patch ready which makes use of the byte order
> transformation and can post it. It adds parameter to
> avrdx_ws2812_register which in turn populates the new fields in struct
> ws2812_dev_s. I don't like this approach very much but I found no
> elegant way to call the upper half from board code directly (which
> would allow board code to enable the feature without the need to alter
> every lower half.)
>
> This is for the documentation cleanup:
>
> ============================
>
> Documentation: cleanups related to WS2812 RGB LED
>
> ## Summary
>
> This patch series removes function description templates from AVR DA/DB
> header file related to WS2812 lower half driver. It also removes
> description of a WS2812 upper half driver configuration option which
> was removed during the review process.
>
> There is no functional change, the patch of the header file only
> removes comments.
>
> ## Impact
>
> **Impact on documentation** - needless code comments removed,
> description of a nonexistent configuration option removed
>
> Otherwise, no new feature added, no impact on users, build, hardware,
> security nor compatibility.
>
> ## Testing
>
> I confirm that changes are verified on local setup and works as
> intended:
> * Build Host(s): Linux, AMD, GCC avr-gcc 14.2
> * Target(s): AVR DA/DB, tested on breadxavr:ws2812
>
> Compiled binary has identical sha256 before and after the change.
>
> ## PR verification Self-Check
>
> * [x] This PR introduces only one functional change.
> * [x] I have updated all required description fields above.
> * [x] My PR adheres to Contributing
> [Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md)
> and
> [Documentation](
https://nuttx.apache.org/docs/latest/contributing/index.html)
> (git commit title and message, coding standard, etc).
> * [ ] My PR is still work in progress (not ready for review).
> * [x] My PR is ready for review and can be safely merged into a
> codebase.
>
> ============================
>
> On 2026-11-02 10:30, Swatantra wrote:
>> Hi Kerogit,
>>
>> The PR (#21338) was already merged into master after all CI checks
>> passed.
>>
>> Casaroli did a thorough pass and caught the remaining items (the
>> upper-half
>> buffer clamping and swint error return handling). Since it was already
>> merged, Marco kindly volunteered to handle the follow-up fixes in a
>> separate PR himself.
>> It was a pleasure shepherding your work.
>>
>> Best regards,
>> Swatantra Yadav
>>
>> On Mon, 2 Nov 2026 at 04:34, <[email protected]> wrote:
>>
>>> Hi, sorry, very sorry, I messed up. I did all those checks I wrote
>>> about
>>> in the previous message but then forgot to mention that the branch to
>>> pull for this last part is named avrdx_ws2812. The _v2 branch has
>>> commits I wanted to ask about at some point later and is not ready to
>>> be
>>> merged (and contains more errors than those you fixed.)
>>>
>>> Again, sorry for the additional work - and thanks for the adjustments
>>> in
>>> points 2-3
>>>
>>> On 2026-11-01 23:30, Swatantra wrote:
>>> > Hi Kerogit,
>>> >
>>> > I have rebased the series onto current master and opened the Pull
>>> > Request
>>> > on GitHub:
>>> > https://github.com/apache/nuttx/pull/21338
>>> > (Title: AVR: WS2812 RGB LED driver)
>>> >
>>> > All 9 commits have been submitted with your full author attribution
>>> > (Kerogit <[email protected]>) and DCO Signed-off-by preserved.
>>> >
>>> > To ensure the patches passed all automated CI checks cleanly on
GitHub,
>>> > a
>>> > few minor adjustments were made:
>>> >
>>> > 1. EXTERN in avrdx_ws2812.h:
>>> > There were leftover #define EXTERN and #undef EXTERN lines in
>>> > arch/avr/src/avrdx/avrdx_ws2812.h. Running nxstyle flagged these, so
I
>>> > removed them to match the clean approach we used in Step 3's
>>> > avrdx_swint.h.
>>> >
>>> > 2. Kconfig choice vs Conditional select for WS2812_NON_SPI_DRIVER:
>>> > In drivers/leds/Kconfig, changing WS2812_NON_SPI_DRIVER into a choice
>>> > symbol caused olddefconfig to fail in CI builds (such as bluetooth
and
>>> > rp2xxx). In Kconfig syntax, symbols inside a choice block cannot be
>>> > selected by external symbols, but arch/arm/src/rp2040 and rp23xx both
>>> > have
>>> > "select WS2812_NON_SPI_DRIVER".
>>> >
>>> > To preserve your exact goal (not forcing SPI when non-SPI is used,
>>> > while
>>> > keeping SPI enabled by default for legacy boards), I updated the
>>> > top-level
>>> > option to use standard conditional selection:
>>> >
>>> > config WS2812
>>> > bool "WS2812 LED Driver"
>>> > default n
>>> > select SPI if !WS2812_NON_SPI_DRIVER
>>> >
>>> > This keeps WS2812_NON_SPI_DRIVER as a regular boolean config,
>>> > completely
>>> > satisfying backwards compatibility while avoiding build failures on
>>> > other
>>> > architectures.
>>> >
>>> > 3. Spelling & Assembly Opcode Whitelisting:
>>> > - Fixed a minor typo (endianess -> endianness) in
drivers/leds/ws2812.c
>>> > flagged by codespell.
>>> > - Whitelisted lowercase "rcall" in .codespellrc so codespell does not
>>> > mistake the AVR assembly instruction in avrdx_ws2812_uart_store.S for
>>> > "recall".
>>> >
>>> > 4. CMake Parity:
>>> > Added [skip-cmake-parity] to Commit 6 to satisfy the NuttX checkpatch
>>> > check
>>> > for AVR's GNU Make build system.
>>> >
>>> > The PR is now live in CI and assigned to maintainers. I will monitor
>>> > review
>>> > discussions and relay any feedback here if needed.
>>> > Thank You
>>> >
>>> > Best regards,
>>> > Swatantra Yadav
>>> >
>>> > On Sun, 1 Nov 2026 at 21:12, <[email protected]> wrote:
>>> >
>>> >> Hi, thanks for posting it and also thanks for removing the EXTERN
>>> >> definition, it was not pointed out by checkpatch when I tested the
>>> >> patches. The next part is submitted with EXTERN removed as well.
>>> >> Checked
>>> >> spelling once more, documentation builds correctly so hopefully you
>>> >> won't have much trouble with this one.
>>> >>
>>> >> Some of the changes in this series are partly intended as
suggestions
>>> >> for discussion. I will watch the PR and if people make some comments
>>> >> and/or request changes, I will respond here.
>>> >>
>>> >> ============================
>>> >>
>>> >> AVR: WS2812 RGB LED driver
>>> >>
>>> >> ## Summary
>>> >>
>>> >> This patch series adds platform-specific driver for WS2812 RGB LED
to
>>> >> AVR DA/DB architecture. RGB data is transmitted using USART
peripheral
>>> >> but the driver is designed to allow other peripherals to be
supported
>>> >> if
>>> >> needed. In addition, there are some fixes for issues discovered when
>>> >> working with existing code - USART control in architecture code and
>>> >> some
>>> >> cleanups in the WS2812 driver upper half.
>>> >>
>>> >> Breadxavr board is updated to provide example configuration that
>>> >> compiles ws2812 program from nuttx-apps to showcase the LEDs.
>>> >>
>>> >> ## Impact
>>> >>
>>> >> **New feature**: driver for WS2812 RGB LED for AVR DA/DB family and
>>> >> example configuration for breadxavr board
>>> >>
>>> >> **Impact on user**: none, new code is not enabled by default. Other
>>> >> AVR
>>> >> families are not supported and not affected, same for other
>>> >> architectures
>>> >>
>>> >> **Impact on build**: new Kconfig options related to the new feature.
>>> >>
>>> >> Also, configuration of WS2812 upper half is altered slightly. The
>>> >> upper
>>> >> half driver initially only supported SPI peripheral and was later
>>> >> extended to interact with architecture lower half instead (in which
>>> >> case
>>> >> the upper half is no longer tied to any specific hardware.) Even if
>>> >> the
>>> >> new style is used and SPI is not needed, the driver enforces "select
>>> >> SPI".
>>> >>
>>> >> The patch series adds a choice between the old and the new style and
>>> >> only the old style selects SPI now. Existing WS2812_NON_SPI_DRIVER
>>> >> configuration option is changed from boolean (default false) to a
>>> >> choice
>>> >> option (default not chosen.) This should be fully backwards
compatible
>>> >> with existing configurations. Default configuration selects the old
>>> >> style driver and existing board configurations with
>>> >> CONFIG_WS2812_NON_SPI_DRIVER=y continue to work without changes.
>>> >>
>>> >> **Impact on documentation**: added documentation for the driver and
>>> >> description of the new configuration to breadxavr board. Description
>>> >> of
>>> >> ws2812_register upper half function in the code is altered to match
>>> >> current parameters of that function. This forced a formatting
cleanup
>>> >> to
>>> >> fix an issue reported by checkpatch before any changes were made.
>>> >>
>>> >> No impact on hardware, security or compatibility
>>> >>
>>> >> ## Testing
>>> >>
>>> >> I confirm that changes are verified on local setup and works as
>>> >> intended:
>>> >> * Build Host(s): Linux, AMD, GCC avr-gcc 14.2
>>> >> * Target(s): AVR DA/DB, tested on breadxavr
>>> >>
>>> >> Tested with ws2812 example application from nuttx-apps. When
executed
>>> >> from NSH, the LEDs light up in green color and then repeatedly cycle
>>> >> colors to yellow, red, magenta, blue, cyan and back to green. This
>>> >> sequence of colors is not expected, first color is supposed to be
red.
>>> >> After an examination, it was found out that the LEDs used for
testing
>>> >> do
>>> >> not behave as documented and interpret the first received byte as
red
>>> >> (instead of green as described by the documentation.) This was
>>> >> confirmed
>>> >> by a simple non-RTOS firmware that drives output pin directly with
>>> >> timing achieved by nop instructions. The driver should therefore
work
>>> >> with LEDs that behave according to the documentation.
>>> >>
>>> >> Documentation checked by make html
>>> >>
>>> >> ## PR verification Self-Check
>>> >>
>>> >> * [x] This PR introduces only one functional change.
>>> >> * [x] I have updated all required description fields above.
>>> >> * [x] My PR adheres to Contributing
>>> >> [Guidelines](
>>> https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md)
>>> >> and
>>> >> [Documentation](
>>> >> https://nuttx.apache.org/docs/latest/contributing/index.html)
>>> >> (git commit title and message, coding standard, etc).
>>> >> * [ ] My PR is still work in progress (not ready for review).
>>> >> * [x] My PR is ready for review and can be safely merged into a
>>> >> codebase.
>>> >>
>>> >> ============================
>>> >>
>>> >> On 2026-10-29 15:46, Swatantra wrote:
>>> >> > Hello Kerogit,
>>> >> > I have rebased the AVR DA/DB software interrupt emulation patch
series
>>> >> > (`avrdx_swint`) onto latest master and submitted the Pull Request
on
>>> >> > your
>>> >> > behalf:
>>> >> > https://github.com/apache/nuttx/pull/21129
>>> >> >
>>> >> > All commit authorship, DCO sign-offs, and checkpatch requirements
have
>>> >> > been
>>> >> > verified.
>>> >> >
>>> >> > Best regards,
>>> >> > Swatantra
>>> >> >
>>> >> > On Wed, 28 Oct 2026 at 05:11, <[email protected]> wrote:
>>> >> >
>>> >> >> Hello,
>>> >> >>
>>> >> >> I noticed that the previous phase got merged - thanks to everyone
>>> >> >> involved. Step 3 is support for software interrupt emulation,
branch
>>> >> >> name is avrdx_swint. Documentation builds without conflicts and
>>> >> >> checkpatch reports all checks pass for every changed source code
>>> file.
>>> >> >>
>>> >> >> ============================
>>> >> >>
>>> >> >> AVR: software interrupt emulation
>>> >> >>
>>> >> >> ## Summary
>>> >> >>
>>> >> >> This patch adds emulated software interrupt functionality to AVR
>>> DA/DB
>>> >> >> architecture. The chip itself does not have any software
interrupt
>>> and
>>> >> >> the suggested way to implement one is to manipulate an I/O pin
>>> >> >> configured to trigger a hardware interrupt. The implementation
can
>>> >> >> serve
>>> >> >> multiple users at the same time and also supports sharing the
>>> hardware
>>> >> >> interrupt of the I/O port with other users.
>>> >> >>
>>> >> >> There is no in-tree user of this functionality yet, intended use
is a
>>> >> >> follow-up patch series that adds driver for WS2812 programmable
LED.
>>> >> >>
>>> >> >> ## Impact
>>> >> >>
>>> >> >> **New feature**: software interrupt emulation for AVR DA/DB
family
>>> >> >>
>>> >> >> **Impact on user**: none, new code is not enabled by default.
Other
>>> >> >> AVR
>>> >> >> families are not supported and not affected.
>>> >> >>
>>> >> >> **Impact on build**: new Kconfig options related to the new
feature,
>>> >> >> none otherwise
>>> >> >>
>>> >> >> **Impact on documentation**: zero latency interrupts guide
updated
>>> >> >> (mentions software interrupt emulation as a way to "get back
into the
>>> >> >> game")
>>> >> >>
>>> >> >> No impact on hardware, security or compatibility
>>> >> >>
>>> >> >> ## Testing
>>> >> >>
>>> >> >> I confirm that changes are verified on local setup and works
as
>>> >> >> intended:
>>> >> >> * Build Host(s): Linux, AMD, GCC avr-gcc 14.2
>>> >> >> * Target(s): AVR DA/DB, tested on breadxavr
>>> >> >>
>>> >> >> Tested with the (not yet merged) WS2812 driver which uses this
>>> >> >> functionality to notify the OS that the data transmission
performed
>>> by
>>> >> >> the zero latency interrupt handler is finished.
>>> >> >>
>>> >> >> Other than that - Documentation tested by make html, changed
source
>>> >> >> code
>>> >> >> files tested with checkpatch.sh
>>> >> >>
>>> >> >> ## PR verification Self-Check
>>> >> >>
>>> >> >> * [x] This PR introduces only one functional change.
>>> >> >> * [x] I have updated all required description fields above.
>>> >> >> * [x] My PR adheres to Contributing
>>> >> >> [Guidelines](
>>> >> https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md)
>>> >> >> and
>>> >> >> [Documentation](
>>> >> >> https://nuttx.apache.org/docs/latest/contributing/index.html)
>>> >> >> (git commit title and message, coding standard, etc).
>>> >> >> * [ ] My PR is still work in progress (not ready for review).
>>> >> >> * [x] My PR is ready for review and can be safely merged into
a
>>> >> >> codebase.
>>> >> >>
>>> >> >> ============================
>>> >> >>
>>> >> >>
>>> >> >> On 2026-10-16 18:20, Swatantra wrote:
>>> >> >> > Hi, No worries at all. Aspell definitely generates a lot of
false
>>> >> >> > positives
>>> >> >> > with embedded hardware terminology, and Sphinx's
autosectionlabel
>>> >> >> > extension
>>> >> >> > is notorious for flagging duplicate headings across sections.
>>> >> >> >
>>> >> >> > That's the beauty of pair-shepherding—catching those CI quirks
>>> >> together
>>> >> >> > makes the upstream submission smooth.
>>> >> >> >
>>> >> >> > The force-pushed commit is now building cleanly in GitHub
Actions
>>> CI.
>>> >> I
>>> >> >> > will keep an eye on the review progress with Alin and the
>>> maintainers
>>> >> >> > and
>>> >> >> > keep you posted here.
>>> >> >> >
>>> >> >> > Best regards,
>>> >> >> > Swatantra Yadav
>>> >> >> >
>>> >> >> > On Fri, 16 Oct 2026 at 21:39, <[email protected]> wrote:
>>> >> >> >
>>> >> >> >> Hi, thanks for posting the patches and for the fixes. I am
>>> >> >> >> spellchecking
>>> >> >> >> the commits as well but there is lot of noise (aspell doesn't
like
>>> >> the
>>> >> >> >> word datasheet, let alone AVR) so it's unfortunately easy to
miss
>>> >> >> >> something. And sorry about the duplicate label, I tested that
>>> >> document
>>> >> >> >> with make html and found and fixed 2 of those warnings but it
did
>>> not
>>> >> >> >> occur to me that this label needs to be fixed in earlier patch
>>> than
>>> >> >> >> where I did it.
>>> >> >> >>
>>> >> >> >> On 2026-10-16 17:00, Swatantra wrote:
>>> >> >> >> > Hi Kerogit,
>>> >> >> >> >
>>> >> >> >> > I have submitted your Phase 2 series (Zero Latency Interrupt
>>> >> Handlers)
>>> >> >> >> > as a
>>> >> >> >> > pull request on GitHub:
>>> >> >> >> >
>>> >> >> >> > PR: https://github.com/apache/nuttx/pull/20706
>>> >> >> >> >
>>> >> >> >> > Details of the submission:
>>> >> >> >> > - Rebased cleanly on top of the latest apache/nuttx master
>>> (which
>>> >> >> >> > includes
>>> >> >> >> > merged PR #20677).
>>> >> >> >> > - Fixed a minor documentation typo ("overriden" ->
>>> "overridden") in
>>> >> >> >> > zerolatencyinterrupts.rst so that GitHub Actions CI checks
>>> >> (codespell)
>>> >> >> >> > pass
>>> >> >> >> > cleanly.
>>> >> >> >> > - Preserved your original author attribution and DCO
sign-off
>>> >> >> >> > exclusively
>>> >> >> >> > across all 4 commits.
>>> >> >> >> > - Validated with checkpatch.sh and cvt2utf (0 errors, 0
>>> warnings).
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > Best regards,
>>> >> >> >> > Swatantra Yadav
>>> >> >> >> >
>>> >> >> >> > On Fri, 16 Oct 2026 at 18:08, <[email protected]> wrote:
>>> >> >> >> >
>>> >> >> >> >> Hello, thanks, I see it merged, next step is zero latency
>>> >> interrupt
>>> >> >> >> >> handling in branch named avrdx_zerolatency_intr. It rebased
>>> >> cleanly
>>> >> >> on
>>> >> >> >> >> current master branch. PR description is:
>>> >> >> >> >>
>>> >> >> >> >> ============================
>>> >> >> >> >>
>>> >> >> >> >> AVR: support for zero latency interrupt handlers
>>> >> >> >> >>
>>> >> >> >> >> ## Summary
>>> >> >> >> >>
>>> >> >> >> >> This patch series provides support for so-called zero
latency
>>> >> >> >> >> interrupts
>>> >> >> >> >> as described in
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >>
>>> >>
>>>
https://nuttx.apache.org/docs/latest/guides/concurrency/zerolatencyinterrupts.html
>>> >> >> >> >> . These can be used for driver code that needs the
interrupt
>>> >> handler
>>> >> >> >> >> to
>>> >> >> >> >> run with as little overhead as possible (for example
because
>>> it is
>>> >> >> >> >> latency sensitive, runs very often etc.) This series does
not
>>> add
>>> >> any
>>> >> >> >> >> in-tree user, that is a topic of a planned follow-up
(driver
>>> for
>>> >> >> >> >> WS2812
>>> >> >> >> >> programmable LED.)
>>> >> >> >> >>
>>> >> >> >> >> This support is only added for DA/DB family of AVR chips.
>>> >> >> >> >>
>>> >> >> >> >> There are also some fixes of interrupt vectors table
>>> (incorrectly
>>> >> >> >> >> numbered vectors as a result of duplicates) and Kconfig
option
>>> >> >> naming.
>>> >> >> >> >> In addition to that, interupt vectors are renamed (for
DA/DB
>>> >> family
>>> >> >> >> >> only) to be able to override them with custom code written
in C
>>> >> (and
>>> >> >> >> >> compiled with GCC which expects __vector prefix in the
name.)
>>> >> >> >> >>
>>> >> >> >> >> ## Impact
>>> >> >> >> >>
>>> >> >> >> >> New feature is added: zero latency interrupts that override
>>> >> regular
>>> >> >> >> >> interrupt routine with a custom code completely
independent on
>>> the
>>> >> >> >> >> rest
>>> >> >> >> >> of the operating system.
>>> >> >> >> >>
>>> >> >> >> >> There is no impact on existing users, all new code is off
by
>>> >> default.
>>> >> >> >> >> No
>>> >> >> >> >> impact on other architectures nor other AVR families
either.
>>> >> >> >> >>
>>> >> >> >> >> Impact on build - some Kconfig options are renamed from
HAS_ to
>>> >> >> >> >> preferred HAVE_ form. This renaming only touches existing
>>> Kconfig
>>> >> >> >> >> options that are referred to by newly added Kconfig options
>>> (ie.
>>> >> the
>>> >> >> >> >> new
>>> >> >> >> >> option depends on the existing one.) All of the renamed
options
>>> >> are
>>> >> >> >> >> selected automatically based on chip in use so this change
>>> should
>>> >> >> have
>>> >> >> >> >> no impact on existing configurations.
>>> >> >> >> >>
>>> >> >> >> >> Impact on documentation - the guide linked in the summary
is
>>> >> updated
>>> >> >> >> >> to
>>> >> >> >> >> describe specifics of the AVR implementation.
>>> >> >> >> >>
>>> >> >> >> >> No impact on hardware, security or compatibility.
>>> >> >> >> >>
>>> >> >> >> >> ## Testing
>>> >> >> >> >>
>>> >> >> >> >> I confirm that changes are verified on local setup and
>>> works as
>>> >> >> >> >> intended:
>>> >> >> >> >> * Build Host: Linux, AMD, GCC - avr-gcc 14.2
>>> >> >> >> >> * Target: AVR DA/DB, tested on breadxavr board
>>> >> >> >> >>
>>> >> >> >> >> To test that the interrupt vector renaming did not affect
other
>>> >> AVR
>>> >> >> >> >> families, mega1284p-xplained:nsh was built and disassembly
>>> >> compared.
>>> >> >> >> >> There was no change.
>>> >> >> >> >>
>>> >> >> >> >> The feature was first tested by rudimentary application
that
>>> >> >> >> >> controlled
>>> >> >> >> >> WS2812 programmable LED outside of the OS and then by a new
>>> driver
>>> >> >> for
>>> >> >> >> >> that LED using ws2812 example application from nuttx-apps.
>>> >> >> >> >>
>>> >> >> >> >> ## PR verification Self-Check
>>> >> >> >> >>
>>> >> >> >> >> * [x] This PR introduces only one functional change.
>>> >> >> >> >> * [x] I have updated all required description fields
above.
>>> >> >> >> >> * [x] My PR adheres to Contributing
>>> >> >> >> >> [Guidelines](
>>> >> >> >> https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md)
>>> >> >> >> >> and
>>> >> >> >> >> [Documentation](
>>> >> >> >> >>
https://nuttx.apache.org/docs/latest/contributing/index.html)
>>> >> >> >> >> (git commit title and message, coding standard, etc).
>>> >> >> >> >> * [ ] My PR is still work in progress (not ready for
>>> review).
>>> >> >> >> >> * [x] My PR is ready for review and can be safely merged
>>> into a
>>> >> >> >> >> codebase.
>>> >> >> >> >>
>>> >> >> >> >> ============================
>>> >> >> >> >>
>>> >> >> >> >> On 2026-10-15 07:41, Swatantra wrote:
>>> >> >> >> >> > Hi Kerogit, Alin,
>>> >> >> >> >> >
>>> >> >> >> >> > I have opened the Pull Request for Step 1 on GitHub on
>>> behalf of
>>> >> >> >> >> > Kerogit:
>>> >> >> >> >> > https://github.com/apache/nuttx/pull/20677
>>> >> >> >> >> >
>>> >> >> >> >> > All 4 commits preserve Kerogit's original authorship and
DCO
>>> >> >> >> sign-offs,
>>> >> >> >> >> > rebased cleanly onto current master, and checked with
>>> nxstyle.
>>> >> >> >> >> > As discussed, we will proceed step-by-step: once this PR
is
>>> >> >> reviewed
>>> >> >> >> >> > and
>>> >> >> >> >> > merged, we can proceed with Step 2 (Zero Latency
Interrupts).
>>> >> >> >> >> >
>>> >> >> >> >> > Best regards,
>>> >> >> >> >> > Swatantra Yadav
>>> >> >> >> >> >
>>> >> >> >> >> > On Thu, 15 Oct 2026 at 03:15, <[email protected]> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> >> Hello,
>>> >> >> >> >> >>
>>> >> >> >> >> >> thanks to everyone for the offers. First part of the
series
>>> is
>>> >> >> ready
>>> >> >> >> >> >> in
>>> >> >> >> >> >> the Git repository, branch is named avrdx_fixes_13.1.
The PR
>>> >> >> >> >> >> description
>>> >> >> >> >> >> is below. I'll be looking at Github and if any question
>>> arise,
>>> >> I
>>> >> >> will
>>> >> >> >> >> >> answer them here.
>>> >> >> >> >> >>
>>> >> >> >> >> >> And just in case - since you mention splitting the
patches
>>> into
>>> >> >> >> >> >> individual PRs. If you mean breaking the branch into 4
>>> separate
>>> >> >> >> >> >> branches, I would advise against that. The features
more or
>>> >> less
>>> >> >> >> >> >> depend
>>> >> >> >> >> >> on each other (software interrupt emulation changes file
>>> added
>>> >> by
>>> >> >> the
>>> >> >> >> >> >> zero latency interrupts, WS2812 uses both of these
features
>>> >> etc.)
>>> >> >> so
>>> >> >> >> >> >> trying to split them up is most likely going to end
with git
>>> >> >> >> conflicts
>>> >> >> >> >> >> and code that does not build. That's why I was planning
to
>>> >> merge
>>> >> >> this
>>> >> >> >> >> >> in
>>> >> >> >> >> >> step-by-step fashion.
>>> >> >> >> >> >>
>>> >> >> >> >> >> The filled PR template:
>>> >> >> >> >> >>
>>> >> >> >> >> >> ============================
>>> >> >> >> >> >>
>>> >> >> >> >> >> AVR DA/DB: fix for build failure and other smaller fixes
>>> >> >> >> >> >>
>>> >> >> >> >> >> ## Summary
>>> >> >> >> >> >>
>>> >> >> >> >> >> This patch series fixes build failure for AVR DA/DB
family
>>> and
>>> >> >> adds
>>> >> >> >> >> >> some
>>> >> >> >> >> >> other smaller fixes.
>>> >> >> >> >> >>
>>> >> >> >> >> >> The build failure was caused by patch series that added
>>> >> >> >> >> >> LIBC_ATOMIC_IRQ
>>> >> >> >> >> >> Kconfig option during 13.1 development. Commit
4ca2256a9bee
>>> >> >> selects
>>> >> >> >> >> >> this
>>> >> >> >> >> >> option by default for AVR chips but not for the DA/DB
>>> family,
>>> >> >> causing
>>> >> >> >> >> >> a
>>> >> >> >> >> >> build failure (atomic functions are missing.) The first
>>> patch
>>> >> of
>>> >> >> this
>>> >> >> >> >> >> series simply adds missing "select LIBC_ATOMIC_IRQ" for
this
>>> >> >> family
>>> >> >> >> as
>>> >> >> >> >> >> well.
>>> >> >> >> >> >>
>>> >> >> >> >> >> Other than that, version 13.1 added a performance
regression
>>> >> which
>>> >> >> >> >> >> manifested as dropped bytes in USART peripheral during
>>> receive
>>> >> >> (with
>>> >> >> >> >> >> heavy round-robin preemptive scheduling load.) The
>>> regression
>>> >> was
>>> >> >> >> >> >> bisected to commit b32712d0a2 that fixes some bugs
(which
>>> were
>>> >> >> >> >> >> affecting
>>> >> >> >> >> >> AVR DA/DB default build as well) but apparently adds
more
>>> >> >> >> >> >> time-consuming
>>> >> >> >> >> >> work to context switch with interrupts disabled. The
patch
>>> for
>>> >> >> this
>>> >> >> >> >> >> simply documents this possibility in the USART driver
>>> >> description.
>>> >> >> >> >> >>
>>> >> >> >> >> >> The remaining patches fix unused variable warning, make
>>> (very
>>> >> >> >> >> >> unlikely)
>>> >> >> >> >> >> board initialization error more visible and reorder
>>> >> manipulation
>>> >> >> with
>>> >> >> >> >> >> stack pointer during context restore to do it in the way
>>> >> >> (presumably)
>>> >> >> >> >> >> intended by the chip manufacturer.
>>> >> >> >> >> >>
>>> >> >> >> >> >> ## Impact
>>> >> >> >> >> >>
>>> >> >> >> >> >> After the patch is applied, it is again possible to
build
>>> the
>>> >> >> code.
>>> >> >> >> >> >> Other than that, there is no impact on existing
code/users.
>>> >> >> >> >> >>
>>> >> >> >> >> >> The stack pointer reordering change is done in file
shared
>>> with
>>> >> >> other
>>> >> >> >> >> >> AVR families - #ifdef blocks are used to cause no
change for
>>> >> them
>>> >> >> >> >> >>
>>> >> >> >> >> >> ## Testing
>>> >> >> >> >> >>
>>> >> >> >> >> >> I confirm that changes are verified on local setup
and
>>> work
>>> >> as
>>> >> >> >> >> >> intended:
>>> >> >> >> >> >> * Build Host: Linux, AMD, GCC-AVR 14.2
>>> >> >> >> >> >> * Target: AVR (AVR128DA28), breadxavr:nsh
>>> >> >> >> >> >>
>>> >> >> >> >> >> Testing logs before change:
>>> >> >> >> >> >>
>>> >> >> >> >> >> ```
>>> >> >> >> >> >> $ tools/configure.sh -l breadxavr:nsh
>>> >> >> >> >> >> $ make -j16
>>> >> >> >> >> >> ...
>>> >> >> >> >> >> avr-ld:
.../nuttx.git/staging/libsched.a(sem_destroy.o): in
>>> >> >> function
>>> >> >> >> >> >> `.L3':
>>> >> >> >> >> >> sem_destroy.c:(.text.nxsem_destroy+0x46): undefined
>>> reference
>>> >> to
>>> >> >> >> >> >> `__atomic_load_4'
>>> >> >> >> >> >> ...
>>> >> >> >> >> >> ```
>>> >> >> >> >> >>
>>> >> >> >> >> >> Testing logs after change:
>>> >> >> >> >> >>
>>> >> >> >> >> >> ```
>>> >> >> >> >> >> $ tools/configure.sh -l breadxavr:nsh
>>> >> >> >> >> >> $ make -j16
>>> >> >> >> >> >> Register: nsh
>>> >> >> >> >> >> Register: sh
>>> >> >> >> >> >> LD: nuttx
>>> >> >> >> >> >> Memory region Used Size Region Size %age Used
>>> >> >> >> >> >> flash: 56377 B 128 KB 43.01%
>>> >> >> >> >> >> sram: 780 B 16 KB 4.76%
>>> >> >> >> >> >> eeprom: 0 B 512 B 0.00%
>>> >> >> >> >> >> rodata: 606 B 4 KB 14.79%
>>> >> >> >> >> >> CP: nuttx.hex
>>> >> >> >> >> >> CP: nuttx.asm
>>> >> >> >> >> >> ```
>>> >> >> >> >> >>
>>> >> >> >> >> >> To verify that the stack pointer change did not affect
other
>>> >> AVR
>>> >> >> >> >> >> families, mega1284p-xplained:nsh was built before and
after
>>> the
>>> >> >> >> >> >> change.
>>> >> >> >> >> >> The resulting binary was identical (with the exception
of
>>> >> version
>>> >> >> >> >> >> string.)
>>> >> >> >> >> >>
>>> >> >> >> >> >> Header and source files were checked by checkpatch with
no
>>> >> issues
>>> >> >> >> >> >> found,
>>> >> >> >> >> >> spelling checked with aspell.
>>> >> >> >> >> >>
>>> >> >> >> >> >> ## PR verification Self-Check
>>> >> >> >> >> >>
>>> >> >> >> >> >> * [x] This PR introduces only one functional change.
>>> >> >> >> >> >> * [x] I have updated all required description fields
>>> above.
>>> >> >> >> >> >> * [x] My PR adheres to Contributing
>>> >> >> >> >> >> [Guidelines](
>>> >> >> >> >>
https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md)
>>> >> >> >> >> >> and
>>> >> >> >> >> >> [Documentation](
>>> >> >> >> >> >>
>>> https://nuttx.apache.org/docs/latest/contributing/index.html)
>>> >> >> >> >> >> (git commit title and message, coding standard, etc).
>>> >> >> >> >> >> * [ ] My PR is still work in progress (not ready for
>>> >> review).
>>> >> >> >> >> >> * [x] My PR is ready for review and can be safely
merged
>>> >> into a
>>> >> >> >> >> >> codebase.
>>> >> >> >> >> >>
>>> >> >> >> >> >> ============================
>>> >> >> >> >> >>
>>> >> >> >> >> >> On 2026-10-14 18:20, Abhishek Mishra wrote:
>>> >> >> >> >> >> > Hi,
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > I'd be happy to help split the patches into
individual PRs
>>> >> and
>>> >> >> >> work on
>>> >> >> >> >> >> > getting them merged. Please let me know how you'd
like to
>>> >> >> >> coordinate.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > Best regards,
>>> >> >> >> >> >> > Abhishek
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On Wed, Oct 14, 2026 at 9:09 PM Alin Jerpelea <
>>> >> >> [email protected]>
>>> >> >> >> >> >> > wrote:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >> please prepare the first patches and I will handle
them
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Best regards
>>> >> >> >> >> >> >> Alin J
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> On Wed, 14 Oct 2026, 16:37 Alin Jerpelea, <
>>> >> [email protected]>
>>> >> >> >> >> wrote:
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> > Hi,
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > I can lend a hand tomorrow
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Thanks for your message
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > Best regards
>>> >> >> >> >> >> >> > Alin
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > On Wed, 14 Oct 2026, 11:18 Felipe Moura Oliveira, <
>>> >> >> >> >> >> [email protected]>
>>> >> >> >> >> >> >> > wrote:
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> Hello,
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> I am away from my desk for the next few days. If
no
>>> one
>>> >> >> offers
>>> >> >> >> to
>>> >> >> >> >> >> help
>>> >> >> >> >> >> >> by
>>> >> >> >> >> >> >> >> this weekend, I will reach out to you so I can
help
>>> you
>>> >> with
>>> >> >> >> this.
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> Regards,
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> *--Felipe Moura de Oliveira*
>>> >> >> >> >> >> >> >> Linkedin <
>>> >> >> https://www.linkedin.com/in/felipe-oliveira-75a651a0
>>> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> On Wed, 14 Oct 2026 at 10:48 <[email protected]>
>>> wrote:
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> > Hello,
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> > I would like to ask someone to help me merge
some
>>> >> patches
>>> >> >> for
>>> >> >> >> >> the
>>> >> >> >> >> >> AVR
>>> >> >> >> >> >> >> >> > architecture, DA/DB family. I have a series
ready
>>> with
>>> >> >> some
>>> >> >> >> >> fixes
>>> >> >> >> >> >> and
>>> >> >> >> >> >> >> >> > some new features. Same as before, I don't have
a
>>> >> Github
>>> >> >> >> account
>>> >> >> >> >> >> so I
>>> >> >> >> >> >> >> am
>>> >> >> >> >> >> >> >> > looking for someone who could open pull requests
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> > The series as a whole is available in my
"nuttx.git"
>>> >> >> >> repository
>>> >> >> >> >> at
>>> >> >> >> >> >> >> >> > git.kerogit.eu accessible through HTTP/S. The
>>> relevant
>>> >> >> >> branch
>>> >> >> >> >> is
>>> >> >> >> >> >> >> named
>>> >> >> >> >> >> >> >> > avrdx_ws2812_upstream .
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> > In its current form, the branch is not suitable
for
>>> >> >> merging
>>> >> >> >> - it
>>> >> >> >> >> >> would
>>> >> >> >> >> >> >> >> > be more than one feature per one PR which is
against
>>> >> the
>>> >> >> >> >> >> contributing
>>> >> >> >> >> >> >> >> > rules. My plan is, if someone decides to help,
to
>>> split
>>> >> >> the
>>> >> >> >> >> series
>>> >> >> >> >> >> >> into
>>> >> >> >> >> >> >> >> > steps and merge these steps one by one. After
one
>>> step
>>> >> is
>>> >> >> >> >> merged, I
>>> >> >> >> >> >> >> >> > would rebase the remainder on current master
branch
>>> and
>>> >> >> >> provide
>>> >> >> >> >> >> next
>>> >> >> >> >> >> >> >> > step. I also plan to prepare text to be filled
in
>>> the
>>> >> PR
>>> >> >> form
>>> >> >> >> >> >> >> >> > (essentialy doing as much as possible to make
the
>>> job
>>> >> >> easier
>>> >> >> >> for
>>> >> >> >> >> >> the
>>> >> >> >> >> >> >> >> > person who will interact with Github.)
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> > There are four features:
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> > 1. fixes - build failure introduced between
13.0 and
>>> >> 13.1,
>>> >> >> >> >> >> documenting
>>> >> >> >> >> >> >> >> > performance regression between these versions
and
>>> some
>>> >> >> minor
>>> >> >> >> >> stuff
>>> >> >> >> >> >> >> >> > 2. zero latency interrupt support -
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >>
>>> >>
>>>
https://nuttx.apache.org/docs/latest/guides/concurrency/zerolatencyinterrupts.html
>>> >> >> >> >> >> >> >> > 3. software interrupt emulation
>>> >> >> >> >> >> >> >> > 4. lower half for WS2812 driver
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >> > Thanks
>>> >> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >>
>>> >>
>>>
