Committed in rS345753.

Looks like it's already committed by kib@

Actually, the code tries to find a 'next' (fallback) rate, which will be used if transmission on the current rate fails; the code will be incorrect, when HT support will be added to the driver (but currently it should 'just work').

In D18742#399973, @imp wrote:

I doubt there's any FreeBSD machines running FreeBSD 6 or newer using APM today. This stopped being relevant around Pentium MMX 200MHz time frame, and was relevant only for laptops. You can safely completely and totally ignore the APM method. We should GC all that code.

igor usr.sbin/powerd/powerd.8
powerd.8:27:date not today, January 4, 2019:.Dd [January 3, 2019]

Both are fine for me - the typical (and the most trivial) test - compile the driver, 'kldunload' the previous one, load newly compiled and commit changes over it.
Right now the new power on sequence is used.

The current version is fine too - I'm using it right now :) But I will take this one to sync with OpenBSD.

Not needed anymore; event handling was implemented in rS342677.

the register is empty for 88e, so you will not see events from it

last time I've seen this code the path for classification was similar to rtwn_pci_intr() -> rtwn_classify() and then (in theory, this does not exist in HEAD yet) should be redirected to r88e_ratectl_tx_completed() when the event arrives

Can you attach next patches with context (like it is described in https://wiki.freebsd.org/action/show/Phabricator?action=show&redirect=CodeReview )

does it really need this loop? (AFAIR, you need to check for arrived event in rtwn_pci_intr() - and then classify it and pass to r88e_ratectl_tx_complete()

Seems to be not needed anymore.

Version which uses libifconfig was accepted / committed instead.

ping? (this part will be needed for Tx parameters - I'm going to store rate indices instead of raw rates in "new" struct ieee80211_txparam)

Drop KASSERT.

Committed in r324657.

Yes (but without reassigning *unit - it will not change after alloc_unr_specific() anyway).

nope; however, libifconfig seems to be more appropriate for such things (so there are alternative versions in D12554 (libifconfig) and D12555 (wlandebug)).

Add some checks against actlen.

Add memory wrap check.

Turn some KASSERT's into checks + add more size checks.

• Add more 'framelen' variable checks.
• Check hdr->len before using it to calculate dlen.

Address some possible buffer over-reads.

I can't test iwn(4) with 4965AGN - firmware throws FH_ERROR's during testing with and/or without this patch when HT rates are in use (A-MPDU / HT40 / SGI status does not matter).
Scanning is not reliable too - sometimes AP is shown on (almost) all 5GHz channels, while it is present on 44th channel only -> this results in NMI_INTERRUPT_WDG error during next scan.

node / mbuf NULL checks now are omitted

not really omitted - just considered as 'correct' - and ignored (see SCD_QUERY status comment + workarounds cannot cover all possible cases).

In D9984#207913, @adrian wrote:

In D9984#207907, @s3erios_gmail.com wrote:

Yeah, this creates unneeded overhead for permanent data flow (and not so noticeable at the end, since it called only once); I will remove it.
BTW, there is another problem: with default ieee80211_ffagemax there is almost no chances to get an aggregate; typically, the queue is flushed earlier.

I was seeing two-frame AMSDUs during UDP TX tests. I'll update my test devices and re-test all of this and get back to you.

Yeah, this creates unneeded overhead for permanent data flow (and not so noticeable at the end, since it called only once); I will remove it.
BTW, there is another problem: with default ieee80211_ffagemax there is almost no chances to get an aggregate; typically, the queue is flushed earlier.

In D9984#206175, @adrian wrote:

The whole M_AGE thing is a bit "special". For fast frames I bet yeah, it's just the right age for the first frame. For the say power save queue, it's supposed to be the age of the frame as a delta from the previous one. If it isn't doing that then it's a bug.

In D9984#206195, @adrian wrote:

Hm, do you think it'd be worth to do something like "ieee80211_tx_end() / ieee80211_rx_end()" as a kind of driver-driven "I've finished TX/RX loop, please do any deferred/interesting work now" in drivers?

I would rather there be something that was generic versus the special cased SUPERG stuff. (And that way we don't need to ifdef it for superg.)

Probably wme_state[4] (in struct ieee80211_wme_state, ieee80211_proto.h) should be removed too?

IMHO, M_AGE_*() is useless for both powersave & stage queues - the first frame always has AGE set to some default value + it is always 0 for subsequent frames; how is it supposed to work?

Init htrateset a bit later

It was additionaly reused for 'rftoggle_task' (and may be reused few more times in future).

s/has/have (twice)

Hmm, so what to do with IEEE80211_F_COMP / IEEE80211_F_TXPOW_FIXED (AUTO/OFF) ?

Other parts look fine.

In D9268#191641, @adrian wrote:

Ideally nodes without NODE_HT / NODE_VHT set won't even do HT/VHT bits. If we have that happening we should fix it. :-)

Fix few typos

I'm unsure about IEEE80211_NODE_* flags setup in ieee80211_ht.c - if user will play enough with ifconfig(8) parameters some nodes may be created without the flag but with ni->ni_htcap and vap->iv_flags_ht bits set.

• Remove IEEE80211_RX_F_DECRYPTED flag setup.
• Call ieee80211_add_rx_params() in rtwn_rx_common() (and drop __DECONST); ieee80211_input_mimo() will check mbuf tag presence anyway.
• Fix possible NULL pointer dereference (after ieee80211_find_rxnode() call).
• Do not try to define R92C_RX_DRVINFO_SZ_DEF in if_rtwnvar.h; it is always included before r92c_reg.h.
• Fix rate mask in r12a_rx_radiotap_flags().

Yes, this is USB NIC.

Committed as a part of rS309210