Just FYI, at least my nightly incarnation wasn't "boot-time".

Hopefully only the changes of this revision this time.

ARG arc. I'll push another one in a minute; this time it diffed against main again and not against its parent.

Fix type.
There is no need to sort pnvm files.
Update pkg-decr to also mention iwx(4).

I tried a similar "way/hack" for LinuxKPI USB code. I didn't particularly like it there but here it seems way more clean.

Also @jhb from looking at the code, on which PCI devices should it be called? I am still confused by the (original) naming of "root". I would assume it's supposedly called on a pcib. Is that correct?

I've run with this since Sep 17 apparently even though my amdgpu was only useable for ~4 weeks during that time frame.

In D53989#1233620, @jrm wrote:

@bz, I installed 15.0 from the memstick image over a wireless connection (Intel ax210 card). This wasn't possible with 14.3, so it's progress. Do you think it's implied that this applies to WiFi chipsets supported by this firmware? I can try to be more specific with something like

The bootonly ISO and mini-memstick image now include the wifi-firmware-iwlwifi-kmod and net/wifi-firmware-rtw88-kmod packages, allowing installations over a wireless connection using Wi-Fi chipsets supported by these firmware. Those with Wi-Fi chipsets that require other firmware should use the DVD ISO.

Does that feel too wordy and more like support than something suitable for a release announcement?

@kib are you still fine with this or is there anything which needs re-testing?

Update return values.

It's gotten silent here. May I ask what the plan is? Is there a chance to get this work into 16?

@kib I'll do the update and push a new revision changing the return values; I had not checked pci_request_region() only the pci[m]_request_regions ones.

In D53904#1231939, @imp wrote:

So I'd like to see the loader patches too before this lands. This strikes me as doing this all wrong, but maybe I'm just missing something.

Thanks! That lately was a source of conflict with the 2-3 commits that came in the last half year.
I still wonder if alternatively we put it into a C file on make in non-static; not sure if it is long-term more stable or if loader can easily link in another USB file?

In D53899#1231632, @glebius wrote:

AFAIU, when arptimer() finds entry in state ARP_LLINFO_REACHABLE it gives it arp_rexmit time (1 second) to get feedback from the forwarding path and sets its state to ARP_LLINFO_VERIFY. In 1 second if feedback was collected, it will issue arprequest(). My concern is that the jitter is bigger than 1 second. I could be wrong, and my concern is erroneous. I just wanted to make sure that this specific behavior is checked to persist. I don't think we have a regression test for it.

In D53899#1231618, @glebius wrote:

In the past we used to have a logic that would renew ARP entires before they expire. The ARP request is sent before an entry is about to be expired. The goal is to avoid to have a doubled RTT on normal traffic every time we renew the entry. I did a quick look around, and failed to find the logic. Is it still there?

My concern is that added jitter may conflict with that. Entries might be deleted earlier than they were tried to be renewed.

If drm-kmod is fixed I think it would be time to flip this switch in 16 now.

I like the idea. I haven't fully wrapped my head around it yet.

rebase

rebase

rebase

rebase

rebase

I added more revisions to the stack in between for other functionality (rtw88/rtw89 to come) and to fix mtw(4) while here.

In D53776#1228267, @des wrote:

Can you please put all of if_iwx_debug.c under #ifdef IWX_DEBUG? A quick LINT build should confirm that none of it is needed (and fwiw print_opcodes() appears not to be used at all, ever).

Update comment in Makefile as to where the firmware list gets generated from now.

After some discussion with someone, we now generate the firmware list
from the WHENCE file in linux-firmware.git given the driver firmware
name creation is too dynamic. This adds some extra firmware files we
did not have before. See files/extract-fw-list.sh.

• remove USES+= kmod and comment
• move BOOT_LOADERCONFD down to the other defines
• add a comment about mtw (mt7601u) and FreeBSD versions.
• add a comment in the logic for writing PLIST file

In D53776#1228090, @adrian wrote:

I don't mind either; in fact the above diffs just remind me i need to finish cleaning up the iwx debug printing so this stuff doesn't require #ifdef IWX_DEBUG everywhere. :-)

I'm happy with landing this and fixnig it in post.

In D53776#1228084, @emaste wrote:

The compile fixes LGTM. I'm indifferent on enabling IWX_DEBUG by default or not -- AFAIK it also has a run-time knob and has no user-facing effect unless turned on, and might be reasonable to leave compiled in given this driver's current status.

In D50928#1228077, @adrian wrote:

If you're worried about the ioctl change then let's do everything except the ioctl changes to begin with, and go fix all the divers and churn net80211's stuff a whole bunch first.

In D50929#1228065, @adrian wrote:

also in my poking I found that I'm not seeing any empty airtime RSSI (it's always 0) so it was setting sc->sc_noise to -127. so we still need to clamp that too to a default noise floor.

In D50929#1228064, @adrian wrote:

hm, i wonder why iwx used -107 as its "nothing present" value. I wonder what iwlwifi is doing too.

like, -107dBm is a very low thermal noise floor; that's like for a 5MHz wide channel. (The noise floor gets higher as the channel width increases.)
But it's a damn sight better than -127dBm. :-)

Are you sure you are not getting full reassembled (re-aggregated) frames on your AX210 that better sees no sequence number checks in net80211 anymore?

Just see https://reviews.freebsd.org/D50929

In D53776#1227867, @des wrote:

This is incomplete. There is a ton of code in sys/dev/iwx/if_iwx_debug.c which will now be compiled but not used.

After some chat with people it seems that the flavors will not fly for newer versions anymore at all.
The driver has a lot less combinations hard-coded and it'll be hard for us for fwget(8) to get any proper mappings from PCI ID to firmware.
"bz" will likely just become "mld" and the "mvm" parts will stay as-are and only be maintained manually in case anything will be found missing or not working.

Seems fine ..

I am reluctant to click on Request Changes for this but maybe you can still fix the local bits before committing.