Re: Request for architectural review: experimental net80211/LinuxKPI HE station support

My dudes, I've already read it all!

It's mostly telling that early up I gotta figure out really why the locking
is showing up in the he state in the node and if so, maybe I should go
create a formal node lock for node state and mark it appropriately.

I'm also going to review the he definitions it brought into the header
files as the first pass to see what's good as is, what needs tweaking and
how it intersects with the rest of linuxkpi.

That PDF though, lol. :-) that's a lot of stuff that doesn't need to be so
verbose. Honestly the code and a test matrix would've been enough to get
started.

Thanks for doing this!


A

On Fri, Nov 6, 2026, 5:28 PM Jordan Hubbard <jordan.hubbard@gmail.com>
wrote:

> [ + @Adrian for viz ]
>
> This discussion captures some of the essential debate I heard in various
> small groups at the FreeBSD Vendor Summit last night:
>
> (A) If you don’t have the skill and the experience to contribute a
> significant new driver but your LLM can, should you?
>
> (A1) What if you submit a small patch to an existing driver using an LLM?
>
> (A2) What if the driver you’re contributing [to] is completely broken?
> What’s the down-side of going from “broken” to “working” even if an LLM is
> involved?
>
> (B) If you are massively experienced in driver creation / modification and
> you use an LLM to generate essentially the same results as A[x], that’s
> fine, right?   RIGHT?
>
> Speaking just for myself, I’m trying to avoid (A) while doing (A1) with
> reviewers who can and are scrutinizing the edits carefully because, as I
> cut releases in the Daemonarchy AI sandbox, I find stuff and I report it,
> like any good OSS citizen, and “upstream" has its own process that it’s
> also in the process of trying to figure out in more detail.
>
> I would say to both Denis and Bjoern that perhaps this is an appropriate
> steam release valve provided by derived projects like Daemonarchy.   You
> want to send projects like mine your PRs or GitHub issues?  Go for it,
>  since the answer to both (A) and (B) is “YES, This is a grand experiment
> with zero-stakes!”   Once new HW support enters such a derived project,
> with releases coming out as often as necessary, the support can be further
> reworked into “upstream shape” with at least some confidence that the HW
> does, in fact, actually boot and send packets, put pixels on the screen,
> make noises from the speakers, whatever.
>
> By contrast, when we merged the PC-98 changes into the tree most of us
> didn’t even know if they worked or not because we did not live in Japan and
> we did not own NEC PC-98 computers, but we took it on faith that it was
> worthwhile (after some debate) because those folks seemed to know what they
> were doing.
>
> Maybe that’s where we’re going next, but with a lot of LLM + human
> reviewers + Real Hardware providing the appropriate change gates.  I can
> only speculate, but I’d be happy to adopt Denis’ patches and see what they
> do in-situ!
>
> - Jordan
>
> On Nov 6, 2026, at 4:47 PM, Denis Lemire <denis@lemire.name> wrote:
>
> If I were to ask you a technical question about something in there, could
>> you answer (without LLM)?
>
>
> As it sits today, without an LLM, there's a great chance the answer would
> be no - I hope to get to that level someday. :)
>
> There's a good, or at least non-zero, chance I could find the answer and
> maybe even understand it, with LLM assistance.
>
> Enjoying the opportunity to learn while exploring the problem space on a
> small scale... Seeking to share successes where I find them.
>
> I personally am bound to a at best "read-only LLM" policy so I couldn't
>> currently even if I wanted to.
>
>
> Thanks for reading and taking the time to reply, regardless of where the
> bread ultimately goes.
>
> If users want to integrate the work into local trees, they are free to,
>> but they will likely also not see (much/any) support?
>> Or would you be able to help them debug problems and will you maintain
>> this code?
>
>
> Although this was all LLM driven, I'm using the target machine in a real
> env and running real workloads on it... It was fascinating to watch the LLM
> work through the problem space... Real dtrace info gathered...crash dumps
> and real results in the end, "on my machine..."
>
> This particular laptop went from struggling to get kilobits per second on
> my WiFi networking, now pretty decently achieves a couple hundred Mbps...
>
> There were a couple real bugs along the way that I raised smaller PRs for:
> https://github.com/freebsd/freebsd-src/pull/2532
> https://github.com/freebsd/freebsd-src/pull/2531
>
> When I saw success with those findings I got curious if the LLM could get
> this hardware to talk 802.11ac/ax on my network. It did!
>
> If anyone does happen to try these patches and has success on their own
> similar hardware or otherwise, I'm happy to collaborate, compare notes,
> methodology etc...
>
> Maybe over time the implementation can prove itself and it could be
> considered merge worthy... if not, maybe it gets someone on-line who
> struggled prior, even if unofficially.
>
> -- Denis
>
> On Fri, Nov 6, 2026 at 5:03 PM Bjoern A. Zeeb <bz@freebsd.org> wrote:
>
>> On Thu, 5 Nov 2026, Denis Lemire wrote:
>>
>> Hi,
>>
>> this is my personal take on this.
>>
>> > I've been developing and testing experimental 802.11ax (HE) station
>> support
>> > for FreeBSD, using an HP laptop with a Realtek RTL8852BT and a UniFi U6
>> > Mesh. I'd appreciate architectural review and guidance on the
>> appropriate
>> > integration route.
>> >
>> > The series connects native HE parsing, encoding and owned association
>> state
>> > to LinuxKPI peer/BSS capability handoffs, rate calculation and receive
>> > metadata. HE defaults off. Testing also exposed separate key/queue
>> ordering
>> > and aggregation-stop lock issues, addressed in distinct commits.
>> >
>> > Source, comprising 21 signed commits based on CURRENT main 12f90bbd3029:
>> >
>> https://github.com/denislemire/freebsd-src/tree/codex/80211ax-sta-review
>> >
>> > Reviewer guide, standalone helper tests and sanitized evidence:
>> > https://denis.lemire.name/download/enabling-he-wifi-in-freebsd.pdf
>>
>> If I were to ask you a technical question about something in there, could
>> you answer (without LLM)?
>>
>>
>> > Fresh CURRENT GENERIC builds with WITNESS and INVARIANTS pass bounded
>> > controls with HE disabled and with HE using software or hardware
>> > encryption. A separately identified STABLE port also passes IPv4/IPv6
>> > traffic, integrity checks, observed pairwise key renewals and automatic
>> HE
>> > startup across a normal reboot.
>> >
>> > Hardware validation is limited to this adapter/AP combination at 40 MHz.
>> > Software encryption remains slower; suspend/resume, broader
>> > interoperability and several lifecycle cases need further work. The
>> guide
>> > distinguishes hardware observations from modeled helper coverage.
>> >
>> > Code, tests and prose were developed with AI assistance; I remain
>> > responsible for their provenance and claims.
>> >
>> > I'd appreciate your assessment of whether this is a useful starting
>> point
>> > for FreeBSD, what needs to change, and how best to get it reviewed. I'm
>> > learning kernel development through this work and would welcome
>> guidance on
>> > bringing it up to the project's standards.
>>
>> I would assume that at this point no (wireless) committer is going to
>> spend any serious time on looking at this to get it integrated.
>> Whether this may change in the future will probably depend on other
>> policies of the project.
>>
>> I personally am bound to a at best "read-only LLM" policy so I couldn't
>> currently even if I wanted to.
>>
>> If users want to integrate the work into local trees, they are free to,
>> but they will likely also not see (much/any) support?
>> Or would you be able to help them debug problems and will you maintain
>> this code?
>>
>> /bz
>>
>> --
>> For there shall arise false Christs, and false prophets, and shall shew
>> great signs and wonders; insomuch that, if it were possible, they shall
>> deceive the very elect. Behold, I have told you before. [Mat. 24:24-25]
>>
>
>