In D49829#1136055, @bz wrote:

In D49829#1136031, @adrian wrote:

oh heh don't forget FEXT_BITS!

YES! I thought about it and did forget it after all given I went and looked at ...

.. @thj I still wonder after checking how iwx gets around that. It seems it does need the addba callback to enable a queue and then sets the ni internals `ni->ni_tx_ampdu[tid].txa_flags = IEEE80211_AGGR_RUNNING;`.
But iwlwifi is very cranky if I even try to send an AddBA Requests. I cannot synch back TID and other information anymore. In fact I hit dead code which contained a bug back in January. It's all just done for us by fw.

oh heh don't forget FEXT_BITS!

ah, this is to entirely bypass even tagging the frames as candidates, right?

ok this is blocked for a lot of bike shed reasons.

I like this!

Yeah, let's both do that (some auditing/review) first.

Is that true though? like, the superg/amsdu transmit path is also queuing the packet and it needs the node reference for it to do so.

In D49767#1135362, @bz wrote:

% git show 02a8d40c9ffb2987c291ea96cf7be7c012b359a3
fatal: bad object 02a8d40c9ffb2987c291ea96cf7be7c012b359a3

In D49767#1135362, @bz wrote:

% git show 02a8d40c9ffb2987c291ea96cf7be7c012b359a3
fatal: bad object 02a8d40c9ffb2987c291ea96cf7be7c012b359a3

Aren't they in 02a8d40c9ffb2987c291ea96cf7be7c012b359a3 ?

In D49765#1135092, @bz wrote:

"Almost none of the drivers (save ath(4), which I fixed a long time ago) implement 802.11 fragments after the big VAP rework done years and years ago. "

Some drivers just say "let me do this in firmware... can you please turn it off?"

I have to validate those bits too soon along with other parts.

oh i agree. It really looks like sam took the ath(4) regdomain tables and threw them into an xml file for net80211.

oops, again, my bad :-)

Interesting, do we not have a pci_get_subdevice() call? @jhb

lol so much existing qc clock code I wrote is not entirley 64 bit clean, so stay tuned. hilarious.

I think it's fine to land as-is and clean it up as we need to.

note - this is just a WIP right now to see how some next bits of bring-up work for the X1E fit on top of it.

Note: approved by bz after the 5 last comments dealt with; so I'll land this shortly.

In D49683#1132904, @manu wrote:

If you're moving files you might as well move them to sys/dev/clk/qcom

remove old stuff

review from bz, also go for a bit of a deep dive into the nonce definitions

review from bz

hi! looks good!

@bz would you mind reviewing this one in particular next? It's just a documentation commit and I'd like to get this landed :-)

@jrtc27 would you mind testing this and do some dtrace probing to make sure ieee80211_recv_bar() is only called when there's a BAR specifically for you? And it's still actually getting called? I'm super paranoid about actually breaking /all/ control traffic now. :-)

more updates from bz/jrtc27

migrate the check to before vap->iv_recv_ctl() is called

I've found myself wanting this a few times since I got back into poking at freebsd on my laptops. Please let's get this into the tree and churn on it in here!

What do y'all think about defining calls to vap->iv_recv_ctl() as receiving "only frames from a known node (where possible), destined to this vap MAC address", so the filtering can be done /before/ the call to vap->iv_recv_ctl() ?