Hi Anchao,
I used Claude to help compare the code and here are the reasons to call it
zblue instead of libs/bt:
Almost all of this PR is Zephyr's Bluetooth stack
("zblue"), reformatted to NuttX style. The part that doesn't come from
Zephyr is
a thin compatibility layer that makes the Zephyr kernel calls work on NuttX.
I pulled all 539 new files (400,450 lines) and compared them against several
Zephyr versions. The closest match is Zephyr v4.5.0-rc2, and it matches
better
than Zephyr's current main branch. So the PR looks like a snapshot of zblue
from the last few weeks.
Results
Function by function (7,716 functions):
Class: Identical
Functions: 5,411 (70%)
Lines: 140,189
Meaning: Exactly the same code as Zephyr. Only indentation and braces
differ.
────────────────────────────────────────
Class: Renames only
Functions: 1,515 (20%)
Lines: 60,863
Meaning: The only changes are API renames that recur across the whole PR:
__ASSERT→DEBUGASSERT (803×), K_FOREVER→((clock_t)-1), sys_slist_*→list_*,
k_mutex_*→nxrmutex_*, k_sem_give→nxsem_post, atomic_get→atomic_read
────────────────────────────────────────
Class: Modified
Functions: 584 (8%)
Lines: 33,693
Meaning: Clearly the Zephyr function, plus some edits specific to that
function
────────────────────────────────────────
Class: Not from Zephyr
Functions: 206 (3%)
Lines: 2,734
Meaning: NuttX glue code
Whole files, including headers:
- On average, 96.9% of each file's code also appears in its Zephyr
counterpart.
- 434 of the 539 files are ≥90% the same as Zephyr; together they hold
375k of
the 400k lines.
- 75% of the comment text, including the Doxygen docs, is word-for-word
Zephyr.
What's actually new:
- The net/bt/compat/ shim layer (kernel/timeout.c, queue.c, mem_slab.c,
fs.c,
sections/defines.c, hci_driver.c), which provides k_work, k_queue and
similar
Zephyr calls on top of NuttX.
- Part of mm/net_buf.
- bt_nus_auto_start_bt.c, which has been heavily extended.
- hci_driver_nuttx.h, the Make.defs files and the sim:bt defconfig.
So, only 3% of the code is new (this includes the code in sim:bt that must
be new).
So, reusing the zblue from Zephyr and calling it something else isn't
right; it's like the zbus that Jorge brought from Zephyr, where calling it
NXBus doesn't seem appropriate.
Besides that, as I said before using ZBlue as our official BT Stack will
significantly increase the shared code between NuttX and Zephyr, which
could be dangerous.
As I said, I not against adding ZBlue to NuttX, but at least make it clear
that it is ZBlue and should be an alternative stack (like NimBLE) not the
official NuttX BLE Stack.
BR,
Alan
On Mon, Oct 19, 2026 at 12:34 AM chao an <[email protected]> wrote:
> Hi Alan,
>
> Thanks for the comments and suggestions.
>
> For the first stage, I would prefer to keep the Bluetooth host stack
> supported only in FLAT mode. Supporting Protected and Kernel modes requires
> a much deeper rework of the stack and its interfaces, especially around the
> boundary between kernel space and user space. I do not think it is a good
> idea to introduce such large architectural changes in this first step.
>
> Our current plan is to complete Protected/Kernel mode support in a second
> stage, after the basic stack integration is reviewed and stabilized. This
> should make the initial review and integration much more manageable.
>
> Regarding the library name, I still prefer to use libs/libbt. Although the
> current code is based on Zephyr's zblue, the goal is to maintain it as an
> independent NuttX Bluetooth host stack going forward, rather than keeping
> it as a direct Zephyr fork forever. In that sense, I think libbt is a
> better long-term name.
>
> Also, the current NuttX Bluetooth profiles are not implemented in the
> kernel, and we do not plan to move the native NuttX Bluetooth stack
> profiles into the kernel either. Once Protected/Kernel mode support is
> added for this stack in the future, this implementation is expected to
> replace the previous approach. For this reason, I think keeping the stack
> under libbt is still more appropriate.
>
> About splitting the PR: this PR is already the result of squashing more
> than one hundred commits. Most of those commits are compatibility-layer
> adjustments, coding style cleanup, and mechanical changes needed to make
> the stack build in NuttX. Asking reviewers to review each of those commits
> separately would probably cost everyone more time.
>
> Splitting the full Bluetooth stack by profile is also not very practical at
> the moment, because there are no dedicated maintainers for each individual
> Bluetooth profile area in NuttX yet. Therefore, I think the current form is
> probably the most reasonable way to review and integrate the stack as a
> whole.
>
> One more update: I have removed all shell-related code from
> https://github.com/apache/nuttx/pull/20686. The plan is to move those
> shell
> commands to apps later. With this change, the current Bluetooth stack no
> longer contains any user-space shell code, so I think this is now a better
> point for review.
>
> Best regards,
>
> Alan C. Assis <[email protected]> 于2026年10月16日周五 21:40写道：
>
> > Hi An Chao,
> >
> > Isn't it possible to have a similar implementation that works for FLAT,
> > Protected and Kernel modes?
> >
> > This way the maintenance will be easier. Only small kernel-specific parts
> > will remain there (as Raiden and Xiang proposed).
> >
> > Suggestion: instead of naming it libs/libbt/, it would be better to use
> > libs/zblue to make it clear that it is a zblue port from Zephyr.
> >
> > Let's use libs/libbt only for NuttX-specific (native) code.
> >
> > And as I said, it is better to easily isolate the code that came from
> > Zephyr's zblue.
> >
> > This way the user could select the Bluetooth stack they want without
> having
> > code from the other stack attached to it.
> >
> > Also I suggest you to break your PR into smaller PRs; a single PR
> changing
> > more than 660K LoC is very massive.
> >
> > BR,
> >
> > Alan
> >
> > On Fri, Oct 16, 2026 at 9:21 AM chao an <[email protected]> wrote:
> >
> > > Hi Alan,
> > >
> > > Thank you for the thoughtful perspective and for engaging in the
> > > discussion.
> > >
> > > On security: we will maintain the Bluetooth stack ourselves and take
> > > responsibility for tracking and fixing vulnerabilities. I'm also
> > confident
> > > that Xiaomi will contribute back on security issues given their ongoing
> > > investment in this codebase. This isn't a blind import — it's code that
> > has
> > > active, committed maintainers behind it.
> > >
> > > Regarding the history with Greg: you're right that we discussed this
> > years
> > > ago. But there's an important distinction — that earlier proposal
> placed
> > > the stack entirely in userspace. It did nothing to strengthen NuttX's
> > > kernel-level Bluetooth support. That's precisely why I'm back now,
> > > providing a kernel implementation this time around, which is what I
> > > committed to back then. Feel free to search the mailing list archives —
> > the
> > > NuttX native Bluetooth stack will evolve from this baseline going
> > forward.
> > >
> > > This implementation does not affect existing Bluetooth stacks in any
> way.
> > > Users can still choose NimBLE, the current NuttX BLE stack, or any
> other
> > > solution. This is an additional option, not a replacement. The goal is
> to
> > > give NuttX users more choices, not fewer.
> > >
> > > One more update: I just spoke with Xiaoxiang and we've reached some
> > common
> > > ground. He's no longer opposed to the current stack implementation and
> > > agrees that the focus should be on proper structuring. Here's the plan
> > > going forward:
> > >
> > > 1. Unused shell code will be moved out of the stack and into apps/,
> > > running entirely in userspace.
> > > 2. Bluetooth profiles will be migrated to libs/libbt/, where we'll
> > > provide two OS API backends: a POSIX API implementation (for
> > > kernel/protected builds) and a NuttX kernel API implementation (for
> > flat
> > > mode).
> > > 3. The L2CAP layer will remain in the NuttX kernel.
> > >
> > > This should address the architectural concerns while preserving the
> > > performance path for flat-mode deployments.
> > >
> > > Alan C. Assis <[email protected]> 于2026年10月16日周五 18:40写道：
> > >
> > > > Hi An Chao,
> > > >
> > > > Thank you for trying to improve the NuttX Bluetooth support. And
> thank
> > > you
> > > > to bring this discussion here to let more people give their opinion.
> > > >
> > > > I think most of the concerns raised by Xiang and Raiden (Mateusz) are
> > > > important and need to be addressed.
> > > >
> > > > As I said at GitHub PR I think a main concern here is using the same
> > > > Bluetooth stack used on Zephyr, not because it is a bad stack (of
> > course
> > > it
> > > > is not, it was developed by experts on Bluetooth area), but because
> we
> > > are
> > > > adding the same surface area of attack from Zephyr on NuttX.
> > > >
> > > > That means any security vulnerability affecting Zephyr BLE stack will
> > > > affect NuttX. It remove the protection that a companies could obtain
> > when
> > > > using different RTOSs.
> > > >
> > > > Also, if my memory still serving me, I think Xiaomi team (you was
> there
> > > at
> > > > that time) already tried to submit their initial port of Zephyr BLE
> > stack
> > > > to NuttX about 4 or 5 years ago and Greg was against it.
> > > >
> > > > His suggestion was to improve our BLE stack, that in fact has the
> same
> > > > origin of the Zephyr BLE stack (both came from a BLE stack from Intel
> > > > released as BSD license at that time).
> > > >
> > > > I'm not against including the Zephyr BLE stack, but it should be
> > > > selectable. Ideally the user should select if he/she wants to use
> > NimBLE,
> > > > Zephyr or NuttX native BLE stack.
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Friday, October 16, 2026, chao an <[email protected]> wrote:
> > > >
> > > > > Hi, Tomek,
> > > > >
> > > > > Thanks for the thoughtful input and the FreeBSD references — those
> > are
> > > > very
> > > > > relevant to where we're heading.
> > > > >
> > > > > Just to set the context: NuttX's current Bluetooth stack only
> > supports
> > > > BLE.
> > > > > Classic Bluetooth (BR/EDR), LE Mesh, and LE Audio are all missing.
> > This
> > > > is
> > > > > exactly why we want to bring a more complete Bluetooth stack to
> > NuttX —
> > > > to
> > > > > catch up with what mainstream RTOS communities already offer.
> > > > >
> > > > > I actually agree with the FreeBSD/Apple architecture you
> referenced.
> > > Our
> > > > > end-state plan is similar: the L2CAP and HCI layers will live in
> the
> > > > > kernel, and a bluetoothd-style daemon will be implemented in libc,
> > > > managing
> > > > > profiles and higher-level protocols. This gives us a clean
> > separation —
> > > > > transport in the kernel, policy and profiles in userspace — much
> like
> > > how
> > > > > FreeBSD's ng_hci / hccontrol split works. The current PR is Phase 1
> > of
> > > > > getting there incrementally.
> > > > >
> > > > > Tomek CEDRO <[email protected]> 于2026年10月16日周五 17:07写道：
> > > > >
> > > > > > Thank you An Chao for this proposition, work, and discussion :-)
> > > > > >
> > > > > > For sure it would be nice to have a BT stack with more features!
> > The
> > > > > > BT has known issue of having different implementations of the
> stack
> > > on
> > > > > > different RTOS / OS / platforms, which is a known issue, and
> kinda
> > > > > > mess because there is no common standard / approach /
> > implementation,
> > > > > > unfortunately around something that is supposed to be based on a
> > > > > > common standard.
> > > > > >
> > > > > > Having common BT stack with other popular RTOS may make
> portability
> > > > > > easier and developers move to NuttX in some cases.
> > > > > >
> > > > > > I understand that we are talking about this solution?
> > > > > >
> > > > > >
> > > > > > https://docs.zephyrproject.org/latest/services/
> > > > > connectivity/bluetooth/index.html
> > > > > >
> > > > > > In a perfect situation we would want to have modular
> implementation
> > > in
> > > > > > nuttx-apps just like nimble. This is pointed out by Xiang,
> Raiden,
> > > and
> > > > > > Alin already. But I understand some things may be hard to
> implement
> > > > > > that way. I will follow the consensus here when ready, I have no
> > > > > > strong opinion here, except any BT stack I touched before was a
> > mess
> > > > > > and I hope we can work out at least something decent :-P
> > > > > >
> > > > > > A bit offtopic but for kernel build we can take a look at quite
> old
> > > > > > Bluetooth implementation on FreeBSD, where radio is provided by
> > > ng_ubt
> > > > > > (lower half in out case), then upper half uses standard HCI.
> Maybe
> > > > > > something like this is possible in NuttX?
> > > > > >
> > > > > > 1. https://man.freebsd.org/cgi/man.cgi?query=bluetooth
> > > > > > 2. https://man.freebsd.org/cgi/man.cgi?query=ng_hci
> > > > > > 3. https://man.freebsd.org/cgi/man.cgi?query=hccontrol
> > > > > > 4. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=3
> > > > > > 5. https://man.freebsd.org/cgi/man.cgi?query=netgraph&sektion=4
> > > > > > 6. https://man.freebsd.org/cgi/man.cgi?query=ngctl
> > > > > >
> > > > > > Here is a quick overview article on the Bluetooth implementation
> in
> > > > > > FreeBSD and Apple:
> > > > > >
> > > > > > https://pkgdemon.github.io/freebsd-bluetooth-management.html
> > > > > >
> > > > > > Again it will be very nice to have fully featured BT stack in
> NuttX
> > > > > > and I hope we can sort out the best possible porting
> implementation
> > > > > > :-)
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > > > > On Fri, Oct 16, 2026 at 8:39 AM Alin Jerpelea <
> [email protected]>
> > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > thanks Xiao and Raiden for your technical opinions which I also
> > > share
> > > > > so
> > > > > > I
> > > > > > > will not iterate them again.
> > > > > > >
> > > > > > > I am against merging this pr in NuttX repo
> > > > > > > it should be splitted between nuttx and apps-repos and use
> POSIX
> > > > > > > implementation as much as possible. We are focused on standards
> > and
> > > > > > > compatibility.
> > > > > > >
> > > > > > > Another concern is the license which does not match our ASF one
> > and
> > > > > does
> > > > > > > not include any LICENSE file additions to clarify the compiance
> > > > aspect
> > > > > > >
> > > > > > > Best regards
> > > > > > > Alin J
> > > > > > >
> > > > > > > On Fri, 16 Oct 2026, 10:12 Xiang Xiao, <
> > [email protected]>
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Fri, Oct 16, 2026 at 3:49 PM chao an <[email protected]
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > > So the real reason you've been objecting to my proposal is
> > that
> > > > > your
> > > > > > team
> > > > > > > > > has been working on something similar, correct?
> > > > > > > > >
> > > > > > > > > If you can give me a clear timeline for when your
> > > implementation
> > > > > > will be
> > > > > > > > > submitted upstream, I'm happy to withdraw my PR and let
> your
> > > code
> > > > > > serve
> > > > > > > > as
> > > > > > > > > the baseline. I'm not here to fight over ownership of the
> > > > Bluetooth
> > > > > > > > stack.
> > > > > > > > > My only motivation is that NuttX's lack of a capable
> > Bluetooth
> > > > > stack
> > > > > > is
> > > > > > > > > driving every developer toward Zephyr — and as a PMC
> member,
> > I
> > > > > think
> > > > > > you
> > > > > > > > > should be asking yourselves why this gap has remained
> > unfilled
> > > > for
> > > > > so
> > > > > > > > long.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > I object to landing the whole bluetooth stack into kernel
> space
> > > > > > directly
> > > > > > > > either yours and ours .
> > > > > > > > This is the same feeling from raiden00pl too, let's see other
> > > > > people's
> > > > > > > > opinions here.
> > > > > > > > But it's fine for me to host the whole code in nuttx-apps.git
> > and
> > > > > > refactor
> > > > > > > > components to kernel
> > > > > > > > space step by step.
> > > > > > > >
> > > > > > > >
> > > > > > > > > As for the current PR, I'll remove the shell components
> from
> > > the
> > > > > > stack
> > > > > > > > and
> > > > > > > > > move them into apps/ where they belong. The base profiles
> > > (A2DP,
> > > > > BLE)
> > > > > > > > will
> > > > > > > > > stay in libc —
> > > > > > > >
> > > > > > > >
> > > > > > > > The architecture is wrong to host any bluetooth profile in
> > libc.
> > > > > > > >
> > > > > > > > in flat build mode this gives a significant performance
> > > > > > > > > boost to the overall stack, which is the primary deployment
> > > model
> > > > > for
> > > > > > > > most
> > > > > > > > > NuttX devices.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > Performance should remain the same whether the base profile
> is
> > > > hosted
> > > > > > in
> > > > > > > > libc or apps,
> > > > > > > > could you point out any technical reason which impacts the
> > > > > performance
> > > > > > in
> > > > > > > > the flat mode?
> > > > > > > >
> > > > > > > >
> > > > > > > > > A few additional data points regarding our timeline: our
> > > product
> > > > is
> > > > > > > > > scheduled for release in December, and Bluetooth SIG
> > > > certification
> > > > > is
> > > > > > > > > already in progress — we expect to receive it around
> > November.
> > > If
> > > > > the
> > > > > > > > > baseline were to switch to your team's stack with its
> > different
> > > > > > > > > architecture, that certification cycle would need to be
> > > repeated,
> > > > > > which
> > > > > > > > is
> > > > > > > > > not trivial given the time and cost involved.
> > > > > > > > >
> > > > > > > > > Xiang Xiao <[email protected]> 于2026年10月16日周五
> > 15:08写道：
> > > > > > > > >
> > > > > > > > > > On Fri, Oct 16, 2026 at 2:44 PM chao an <
> > [email protected]
> > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi raiden00pl,
> > > > > > > > > > >
> > > > > > > > > > > Regarding your point about the NimBLE port using the
> > POSIX
> > > > API
> > > > > —
> > > > > > yes,
> > > > > > > > > it
> > > > > > > > > > > uses POSIX, but there are real issues with the current
> > > > > > implementation
> > > > > > > > > > that
> > > > > > > > > > > go beyond just kernel/protected mode support.
> > > > > > > > > > > 1. ble_npl_hw_enter_critical is not a real critical
> > section
> > > > > > > > > > >
> > > > > > > > > > > Look at the NuttX port's implementation:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > porting/npl/nuttx/src/os_atomic.c
> > > > > > > > > > >
> > > > > > > > > > > static pthread_mutex_t s_mutex =
> > > > > > > > > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> > > > > > > > > > >
> > > > > > > > > > > uint32_t ble_npl_hw_enter_critical(void)
> > > > > > > > > > > {
> > > > > > > > > > > pthread_mutex_lock(&s_mutex);
> > > > > > > > > > > return 0;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > This is a mutex, not a critical section. It does not
> > > disable
> > > > > > > > interrupts
> > > > > > > > > > or
> > > > > > > > > > > preemption — an ISR can still fire and corrupt data
> that
> > > the
> > > > > > > > "critical
> > > > > > > > > > > section" was supposed to protect. On top of that,
> using a
> > > > mutex
> > > > > > opens
> > > > > > > > > the
> > > > > > > > > > > door to ABBA deadlocks when combined with any other
> lock
> > > held
> > > > > > inside
> > > > > > > > > the
> > > > > > > > > > > critical region:
> > > > > > > > > > >
> > > > > > > > > > > - Thread A: enter_critical → lock(s_mutex) → try
> > > > lock(mutex
> > > > > > M) ←
> > > > > > > > > > blocked
> > > > > > > > > > > by B
> > > > > > > > > > > - Thread B: lock(M) → enter_critical →
> lock(s_mutex) ←
> > > > > > blocked by
> > > > > > > > A
> > > > > > > > > > >
> > > > > > > > > > > Compare this with the FreeRTOS port, which correctly
> uses
> > > > > > > > > > > vPortEnterCritical() / vPortExitCritical() (i.e.,
> > actually
> > > > > > disabling
> > > > > > > > > > > scheduling/preemption). The current NuttX port simply
> > does
> > > > not
> > > > > > meet
> > > > > > > > the
> > > > > > > > > > > semantic contract that the NimBLE stack expects from
> > > > > > > > > > > ble_npl_hw_enter_critical.
> > > > > > > > > > > 2. Time subsystem uses clock_gettime instead of kernel
> > tick
> > > > > APIs
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > https://github.com/apache/mynewt-nimble/blob/master/
> > > > > porting/npl/nuttx/src/os_time.c
> > > > > > > > > > >
> > > > > > > > > > > ble_npl_time_get() is backed by
> > > > clock_gettime(CLOCK_MONOTONIC,
> > > > > > ...),
> > > > > > > > > > which
> > > > > > > > > > > involves a syscall and floating-point arithmetic on
> every
> > > > call.
> > > > > > In a
> > > > > > > > > BLE
> > > > > > > > > > > stack where timestamps and timing are on the hot path,
> > this
> > > > > adds
> > > > > > > > > > measurable
> > > > > > > > > > > overhead compared to accessing the kernel tick counter
> > > > > directly.
> > > > > > > > > > > 3. Others are already using the kernel approach — and
> for
> > > > good
> > > > > > reason
> > > > > > > > > > >
> > > > > > > > > > > A concrete example: Xiaomi's Bluetooth stack (zblue)
> for
> > > > > > > > openvela/NuttX
> > > > > > > > > > > uses kernel APIs directly, bypassing POSIX for the
> > > > > > > > performance-critical
> > > > > > > > > > > paths:
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > >
> > > > > > > > > > > This isn't an academic exercise — it's a production
> > choice.
> > > > > They
> > > > > > > > > > recognized
> > > > > > > > > > > that a BLE stack needs tight integration with the OS
> > timer
> > > > > > subsystem,
> > > > > > > > > > > direct access to critical section primitives, and
> > efficient
> > > > > event
> > > > > > > > > > delivery,
> > > > > > > > > > > none of which POSIX provides well in this context.
> > > > > > > > > > > My question
> > > > > > > > > > >
> > > > > > > > > > > If other organizations are already using a more
> > performant,
> > > > > > > > > > architecturally
> > > > > > > > > > > correct kernel-level integration for their BLE stacks
> on
> > > > NuttX,
> > > > > > why
> > > > > > > > > > should
> > > > > > > > > > > we be told that we must use the slower, less correct
> > POSIX
> > > > > path?
> > > > > > > > > NuttX's
> > > > > > > > > > > POSIX compliance is valuable, but it shouldn't come at
> > the
> > > > cost
> > > > > > of
> > > > > > > > > > shipping
> > > > > > > > > > > a BLE stack with a broken critical section primitive.
> > There
> > > > > > should be
> > > > > > > > > > room
> > > > > > > > > > > for both approaches, and the decision should be driven
> by
> > > > > > technical
> > > > > > > > > > merit,
> > > > > > > > > > > not by treating POSIX as the only acceptable answer.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > I don't object to moving the key bluetooth stack to
> kernel
> > > > space
> > > > > > like
> > > > > > > > how
> > > > > > > > > > the current bluetooth stack is done,
> > > > > > > > > > what I object to is that the current state of
> > > > > > > > > > https://github.com/apache/nuttx/pull/20686 is far to
> move
> > > > > entirely
> > > > > > > > > > into kernel space.
> > > > > > > > > > If I low my quality bar, I have requested my teammate to
> > > > upstream
> > > > > > our
> > > > > > > > > > implementation:
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://github.com/sprhawk/zblue-port-openvela/tree/yaotepai/port/kernel
> > > > > > > > > > since much work needs to be done before it can achieve
> the
> > > > > quality
> > > > > > > > > > upstream.
> > > > > > > > > > BTW, many zephyr class BT features are developed by my
> team
> > > and
> > > > > > > > upstream
> > > > > > > > > to
> > > > > > > > > > Zeprhy community.
> > > > > > > > > > If considering the quality, our version is much better
> > since:
> > > > > > > > > >
> > > > > > > > > > 1. Product on smart speaker last year
> > > > > > > > > > 2. Pass Bluetooth SIG BT/BLE 6.2 certification at
> > 2026.06
> > > > > > > > > > 3. Product on wear device by end of this year
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
