It's looking better, can you delete some of the if_run function definitions that aren't in the openbsd rtw driver?

oh yeah, ar9300_freebsd.c is a mess between the AR5416 camelcase and AR9300 "We wanted to land this in upstream linux so we renamed everything" linux case. :)

ok, I've changed this to sit behind RTWN_DEBUG now.

hide behind RTWN_DEBUG for now, feedback from bz/imp

updates from fuz / bz review

Note: this is useful information /with/ the build info, and perhaps some chipset specific stuff like the mac ID / chip revision ID that identifies chip versions / production lines. This stuff will all aid in figuring out regressions / bugs when things work for A but not for B.

In D48067#1099605, @imp wrote:

In D48067#1099602, @adrian wrote:

In D48103#1099187, @fuz wrote:

Can this code be deduplicated and shared between the two driver instances?
The loop feels like it could be eliminated, e.g. with code like

uint32_t supported;

supported = 0xaaaa & ((1 << sc->ntxchains) - 1);
tx_mcs |= IEEE80211_VHT_MCS_SUPPORT_0_9 * supported;
tx_mcs |= IEEE80211_VHT_MCS_NOT_SUPPORTED * (0xaaaa - supported);

supported = 0xaaaa & ((1 << sc->nrxchains) - 1);
rx_mcs |= IEEE80211_VHT_MCS_SUPPORT_0_9 * supported;
rx_mcs |= IEEE80211_VHT_MCS_NOT_SUPPORTED * (0xaaaa - supported);

Though it seems that would be a lot less clean than what you currently have.

In D48067#1098399, @bz wrote:

more suggestions from fuz@

make them all static***

i think maybe we should do both - I can add a check_tx_vht160 and check_tx_vht_80p80 that will check each of the channel configs appropriately, and then a top-level function that does it based on a switch. That way each function is clean, and we can make them all inlines.

aha, talking with manu, there's something off with my install here, those files SHOULD exist in /boot/firmware but don't.

In D48208#1099323, @bz wrote:

If you do not need the old firmware anymore please remove it entirely and update the documentation.

There is HOWEVER a theoretical problem there: if iwlwifi ever bumps the firmware version, say for a security update, there is not guarantee that iwm can parse them properly.

update again!

updated, please re-review! thanks!

oops, also fix this

updates from fuz@, thx!

update with working protection mode logic for firmware rate control

Implement rts/cts programming w/ firmware rate control config.

• fix fls() offset bug, it starts at 1, not 0
• allow more CCK rates and OFDM up to 24, after consultation with other wifi community people

i could forsee someone writing something like a network manager plugin that doesn't specifically just want to call and parse shell output.

(also nice work!)

out of curiousity - what do people think about extracting a bunch of code out of umbctl and stuffing it in a library that can be reused?

oops, renaming/refactoring issue!

We can sit on this one and the next one in the stack and just continue reviewing/landing diffs above it until I get further along this stack and start using the dynamic rate adaption mask stuff.

add a bounds check, suggested by bz

In D48067#1097443, @bz wrote:

Given this is a RTWN_DPRINTF I don't see how that will help any reports.
But if you boot -v (bootverbose) you'll get reports like:

firmware: 'rtwn-rtl8821aufw' version 111: 27804 bytes loaded at 0xffffffff83878000

Is that helpful? Maybe we should add a if (bootverbose) to print this information like other drivers do?

It's in rtw88xx.c:rtw88xxa_tx_power_training(), line 1609 in my checkout.

updated, please review!

request from bz

ok, try this!

update from rebase

update from rebase

use bool; requested by bz@

I'm talking with the rtw88 upstream maintainers on getting it fixed upstream too!

update from another rebase attempt

In D47987#1097419, @bz wrote:

Commit message: "to aid" (without e; aide is a noun).

Some rNNxx_attach.c seems missing (initialization) again/still or this patch is not incremental to a previous one in the stack which means the stack as-is was never tested to even build?

I take that back; the 92eu is added here which was missing in the previous change and that's why the value is added and not changed. Best to be migrated to D47979 to avoid further confusion.