I have to trouble with the move.

@cc any final comments before this goes in?

I was about to commit that but then realized I probably cannot? This is needed. I need to bump priority here.
Otherwise I'll change the return into a false, leave the pr_debug() message (adding the review) and remove the struct field for now?

Thanks a lot for doing it and taking the time. It was last year and the this year hard for anything to step up despite that I had asked at some point on wireless (interested parties) and added ports committers as subscribers.

I compared this to a pre-flavor version I had (which never was in Phab).
Flavors were an after-though for this revision after manu requested the firmware to be broken up in D44918.

In D44865#1034261, @imp wrote:

git arc patch -c might work too

Update comments as suggested by @cc

Do you have this staged somewhere in git I can pull it from?

In D45293#1033438, @bz wrote:

In D45293#1033418, @bz wrote:

There may be another code path which can still trigger this (or another) problem leading to a FW crash with the old 8xxx/9xxx cards (leading to follow-up KASSERT triggers on GENERIC).

I'll have a look tomorrow; in case you see anything but

iwlwifi0: lkpi_sta_scan_to_auth:1310: mo_sta_state(NONE) failed: -5
iwlwifi0: lkpi_iv_newstate: error -1 during state transition 5 (RUN) -> 2 (AUTH)

after a firmware crash, please follow up here or on the PR and let me know.

Doh! https://reviews.freebsd.org/D43967 never made it; the description needs updating etc. but the change should go into main as well; it's likely I hit that race. Grrr decade old net80211 problems everyone ignored.

In D45293#1033443, @imp wrote:

Taerdown -> teardown in commit message.

In D45293#1033418, @bz wrote:

There may be another code path which can still trigger this (or another) problem leading to a FW crash with the old 8xxx/9xxx cards (leading to follow-up KASSERT triggers on GENERIC).

I'll have a look tomorrow; in case you see anything but

iwlwifi0: lkpi_sta_scan_to_auth:1310: mo_sta_state(NONE) failed: -5
iwlwifi0: lkpi_iv_newstate: error -1 during state transition 5 (RUN) -> 2 (AUTH)

after a firmware crash, please follow up here or on the PR and let me know.

I'll try to deal with the "pr_debug" marked instances the next days.

In D45293#1033422, @imp wrote:

"Tear"

There may be another code path which can still trigger this (or another) problem leading to a FW crash with the old 8xxx/9xxx cards (leading to follow-up KASSERT triggers on GENERIC).

So silly question: what are we trying to solve with these packages in first place?
Historic value to have a copy of the packages saved before they disappear?
Give users a graphical desktop (unlikely with this list)?
Because we always did?
...?

Anyone any comments? Otherwise I'll put that in soon.

Anyone? As otherwise this will go in within 24h.

Anyone? Otherwise this will go in within 24h.

@jrm given I am not a ports committer how do I proceed? I assume I need an Approved by: line from someone?

@manu if you are (still) happy with the updated versions, the ports/packages are coming as well (see D44945).
I think we are getting more "stable" now in between supported versions and "noise".
Also while this adds forward matching at least for Intel (the firmware flavor for sc does not exist as the firmware is not public yet), shipping it like this means that after a release we can add the firmware package and the driver and fwget will already support it.

Re-genertae them based on updated scripts.

Update firmware to 20240513 (I have locally updated the commit message).
Also sort out some iwlwifi bits (we try to find the best supported
firmware version if the latest does not exist; may not have made a difference
to the lastet review version?)

In D45205#1031216, @manu wrote:

The main reason for this change is that now struct mtx and spinlock_t are 100% interchangeable in code which is a first step to share structures between linuxkpi driver and native ones.

Funny enough we have no way to destroy this; thankfully witness doesn't track it...

Duplicate the implmentation and add a comment for kvmalloc/kvfree in slab.h

In D45181#1030842, @emaste wrote:

Do we have our approach documented somewhere? This looks acceptable given that we already #define kvfree(arg) kfree(arg) but it would be good to have that mentioned somewhere.

Apart from the () I am fine. if @jhb doesn't commit it I can.

I'll add the back reference to the PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247545

Should be fine; otherwise we'll deal with it as needed; do we know what mii_mpd_rev 7 is/was?

In D44774#1027883, @kp wrote:

In D44774#1027778, @bz wrote:

I'll reply here rather than the email--one well two major concerns (and I didn't mean legal) with the "can of worms" are:
(1) You are adding VRRP version 3... someone will come next and ask "and what about VRRP version 2"?

Right now the answer is "We don't have v2, and we have no plans to support v2 either.".
If someone does ever want to add VRRPv2 support they get to deal with the fallout. I'm not inclined to copy/paste chunks of code on the off chance that maybe it'll be slightly helpful in the future.
We're not making choices that'll make that impossible to do in the future.

(2) We are adding to but not fixing the problem of the conflicting version number; it's easy to say I can add v3 but ... see (1).

As in carpv3? That seems entirely unlikely to ever happen, given that carp's entire reason for existing is now moot.

I'll reply here rather than the email--one well two major concerns (and I didn't mean legal) with the "can of worms" are:
(1) You are adding VRRP version 3... someone will come next and ask "and what about VRRP version 2"?
(2) We are adding to but not fixing the problem of the conflicting version number; it's easy to say I can add v3 but ... see (1).

Is there any implementation for these new functions, i.e., something which updates the drivers or is this just dead wood swimming down the river?

Would be great if the commit message would mention IEEE80211_CRYPTO_MODULE() somehow so one can find this in the future more easily.

In theory I am fine with this once these modules actually exist. I would also fantastic if the annoying printf instead of loading them could be fixed. reverse order.

Most of the comments were marked "done" and changed some since the original comments but the "RSN AKM suite element" table still has a mix of #define suffixes and comments for the "256" cases? Is this on purpose for some reason beyond this file? At least the TDLS case I had originally asked for _256? I just wonder why not? Can you explain?

This still has changes not marked "done".
Is there a change in the stack which does change the drivers to use this?

You didn't answer my previous question?

Can you please update the commit message? Apart from that it seems fine-ish with what cc@ said.

fold the three $MKDIR into one as suggested by @jrm.

Rebuild all the wifi-firmware flavors from scripts, this time hopefully with lower case names.

Update one more time to (hopefully) have all ports/pkackage flavors in lower case.
Also the new files are all script generated.
The scripts will be pushed to github with the next update there before going into main.

Otherwise I am really happy to see the linuxkpi_*.c file in common/src given I keep meaning to say that we should rename them all away from linux_?

I can do the rename.

What is going to happen to sys/modules/linuxkpi_hdmi then? They both compile in linux_hdmi.c (okay, saw the other revision) We do not get symbol clashes?

Why not? Is that not just passing the result back to the caller at the end of the shell function?
Given I have to ask this, I am probably not the right one to review...

Ports change part I here: https://reviews.freebsd.org/D44945