I do understand the problem. I just think the name is a bit futuristic and not very descriptive for what it is doing.

So i was thinking if we can start using ieee80211 for standards things and use a net80211 prefix for our own stuff (at least for anything new or we change)?

For once the if_printf changes are in

Please add:

Need to check all the other places which may have changed implicit behaviour too and they all need the same comment,

In D49773#1155343, @thj wrote:

Setting the regdomain on iwlwifi cleared this out - sorry for the testing delay.

I'm starting to think regdomain is one of our bigger issues.

I believe apart from possible startup issues this is no longer needed for the AX21 compared to what is in main and stable/14?

In D49773#1155062, @thj wrote:

I've sent test output via email. With 160MHz configured on my ap and it beaconing iwlwifi doesn't pick a vht rate for the band, just 80211a

In D50555#1154134, @adrian wrote:

technically (cry) ucast will eventually be keyix 0 and keyix 1, but not the WEP/global slots. Aiee. :-)

In D50552#1154113, @emaste wrote:

OK, but also curious why the ioctl is ..._WPAKEY for WEP support/warnings

Rates to both (when physically near) at about 550Mit/s.

I added logging to ieee80211_vht_get_vhtflags and we never set can_vht160.

Let me know what output you would like to debug with and I can share it via email

In D49773#1153842, @mark_freebsdfoundation.org wrote:

I've also tested it today, and things are much the same as they were. I'm finding conflicting information as to whether the base station I'm connected to supports 160 wide channels or not. Some resources I find say yes, some say no (it's a TP-Link Deco M9Plus - which is 'AC2200' it says). Either way, I'm not getting a 160 connection, and ifconfig still shows -vht160:

Ok, it's been sitting here for another month. Is there anyone who knows this stuff (maybe natively) and could review it?

I've had a few people try this at least with no ill effects (though I am not sure they could test VHT160). @thj can you test the net80211 part?
I don't know otherwise what to do with it as it's been sitting here for a month now.

just style; so do and push them; no need to upload again

Just style.

LGTM minus the -

Fix typo in commet

Scrolling through apart from the local variable this looks good.

LGTM

If you remove the local variable then this is fine (it's also fine this way). I may not see this again before Thu so please go ahead.

Scrolling through again this looks good. Thanks a lot for all the follow-up changes (incl. the extra one folding the ic_printf arguments into one line :) ).

Update as said + Sponsored again.

@ziaee @emaste Do you think this is sufficiently okay to get in? I might want to merge it to 14.3 still.

Anyone for this one?

Add a paragraph about the naming of the tunables.

Address feedback from @ziaee

I've been running this since Saturday for wifi and i915.

Sorry I don't know; this window came up in a restored browser session; I thought I had submitted this ages ago.

In D50005#1146250, @dumbbell wrote:

This looks good to me.

The part that confused me is the name and implementation of ktime_divns(): I wonder if ktime_divns() should "convert" its ktime_t argument to nanoseconds first with ktime_to_ns(). It would be a no-op but just to clarify that it works with and returns nanoseconds, even though the argument is a ktime_t.