Logic seems fine to me.

In D50747#1188607, @bz wrote:

On 2nd though, nothing guards against ieee80211_output_seqno_assign() being called twice. Can we be sure net80211 in no case has a seq# assigned to wh? Or should ieee80211_output_seqno_assign() assert that if tid_arg is -1 that tid from from the frame is 0?

I just leave this comment here; it came to my mind based on the next review; I also think we should carefully define what IEEE80211_FEXT_SEQNO_OFFLOAD means with a comment in net80211 as it does not necessarily mean hardware offload like others but could also mean driver offload?

ok, reduced to one line diff, please re-review! thanks!

comment from bz

Abandoning, but it landed!

landed in rGdff11c4f8007

update

In D52301#1196749, @adrian wrote:

Yeah I was /just/ thinking about squishing them together into one commit.

Do I do that and just have two Differential Revision lines in the commit message?

Yeah I was /just/ thinking about squishing them together into one commit.

👍 Still think you want to squash this one into D52301 or reduce this to the simple "enable offload" as the other functional changes are cleaned up already in D52301

I've tested these with the suggested changes / questions and it works fine, so I'll clean up the diffs tonight and land em. Thanks bz!

remove the % operator in the driver now that the net80211 macros do it for us

In D52300#1194454, @bz wrote:

If you say so; wonder what iwx tells firmware about SMPS?

If you say so; wonder what iwx tells firmware about SMPS?

Based on your description it sounds more like you want to disable PS in net80211 and leave it to iwn?

If you say that's right for rtwn generally...

Change order of commits. And squash the updated this one into D50693?

Testing I leave to you then; you know these devices and drivers better than I do. Scrolling through looked ok.

I cleaned up the seqno assignment stuff in D52301 and D52302. In particular after D52302, we can sweep the drivers and remove the "% IEEE80211_SEQ_RANGE" because, well, it's now done in the macro.

request from bz

oops, forgot to add iwn(4)

Again; you know the drivers better; I was wondering about iwm; are we sure this is true for all cases?

Again: if you tested them... I have no insights into them.

If it works go ahead; I have no insights in the driver internals; the run comments also apply here I guess that we want to make sure we do not double-assign/increment by accident.

I have no idea about the internals of this driver; if you say it works go ahead:

On 2nd though, nothing guards against ieee80211_output_seqno_assign() being called twice. Can we be sure net80211 in no case has a seq# assigned to wh? Or should ieee80211_output_seqno_assign() assert that if tid_arg is -1 that tid from from the frame is 0?

I know not much about tun internals; it looks okay but you need to know and test.

The commit message needs to be updated before commit!

Ignoring the open question on the TODO this seems fine.

note: i haven't yet tested iwi, bwi, bwn - but i found the hardware, so i'll test it next week.
everything else has been tested.

Stuck on athn_usb_detach code or executes athn_usb_stop multiple times
I suspect this is due to the msleep on one threat and a wakeup on another, but I am not certain how to isolate the problem.

As far as I can tell this is nop, but good ground work for future stuff.

re-add missing multicast check, thanks bz!

fix the seqno update routines to wrap things appropriately.
This bit me when doing some work on if_rsu

Address bz's comment - yup, this works with seqno offload and
with it just not populated in the driver encap path. Neat!

Note: my hope is to eventually delete the TX lock entirely; this sets the ground work to first experiment and test various drivers in this stack.

Just scrolled through again. Seems good.