device_printf() isn't a Linux API. Help me understand, maybe with an example, of why we'd need/want it to work there. The rewriting can be done with an inline block, so extra variables don't matter so much (I mean, it is the kernel, but I don't think this would break the bank).

In D48678#1110205, @bz wrote:

In D48604#1111570, @adrian wrote:

updated; now it actually does do _HT and _VHT as separate rates, although both LEGACY and HT set dot11rate. That simplifies everything else.

In D48763#1112273, @imp wrote:

If we start this ..

This is covered by other local changes already to catch the skb in the error case and not the problem for the PR.

Hopefully w/ the pci.c change this time.

@dumbbell can you check drm-kmod will be fine on all relevant branches with this too (especially the older ones)?

Actually not requesting changes yet but more requesting discussion ...

I think the commit description needs updating to kbit/s.

I was pondering this for a while -- also for other devices -- but I highly felt that usbconfig wanted some improvements first to make this a lot easier.
There are tricky bits with USB devices changing "identity" depending on quirks or other state (i.e., first show up as CD-ROM and then become a network device).

The skbs are still leaking even with this so it should be elsewhere.

I'll try to do both the testing and a review in the next 72 hours if that is ok.

I just looked through the delta changes, so the original comment about the duplication assumption stays. The changes seem fine. Thank you for doing them!

Fix another typo.

It's a helper function; because we do use mallocarray internally and it doesn't go by Linux guarantees on memory being physically contiguous in some cases. I can replace all the mallocarray calls directly with __kmalloc() but that just makes it harder to maintain in many places rather one. We can name this whatever we want it to be if you do not like the name...

@salvadore ? Can you approve as well?

In D48113#1100606, @adrian wrote:

In D48113#1099180, @fuz wrote:

Not a big fan of #if 0. Can we either remove this entirely (it can be restored from git history if required) or put it behind a sysctl?

I'd rather leave it as #if 0 for now until I finish bringing up 11ac TX path and can properly dig into what's actually going on here.

It's possible that it's actually beneficial to force the RTS/CTS bandwidth versus letting the MAC do it; heck it could be the MAC is NOT sending RTS/CTS on other channels in wider channels (it needs to duplicate it for each 20MHz channel).

What I do know is the vendor driver and linux effectively ignore this field entirely and simply set it (by not setting it) to 0, but that doesn't mean it's "correct".

So, is a promise I'll go sort it out in more detail later enough? :-)

Adjust the comments and good to go I would say.

There are pending requests fr changes from @fuz and me here.

One question from me (which may or may not lead to a follow-up change) and one request for change from @fuz

@adrian, do you want to update according @fuz 's requests?

Ok, so where do you want to take this? Find all the places in the tree and replace them, just do net80211 and leave the drivers? Just add the macros and let someone else do them all in a go?

Not reviewed just expressing my indifference on this. I would rather see us getting other bits going and demote iwm.

Do you really want to pull 11n into iwm(4) still? Or do we have bigger fish to fry?

Assuming you did the c&p replication in full this seems fine as a start modulo style.

Note: I believe the logic here needs to be reversed and we need to check for 80P80 first. (otherwise we'll never hit the else if case). If anyone agrees with me I'll open another review for that once this is in.

As hinted by @emaste hide the -vht under ifconfig -v as well to be
consistent. I'd rather do it once and for all now than having to
start again. I am typing -v anyway all the time while developing
(given not even pre-vht stuff is all consistent as we have pointed
out in the other review).

In D48319#1102044, @adrian wrote:

So, yeah, let's land this diff, then go fix +vht / -vht to clear/set FVHT_VHT and verify that does the right thing, without having to set/clear all the flags.

I think a good mini project for someone is to turn the HTCONF ioctl bits to actually use defines, not magic numbers. :-)

In D48319#1102010, @adrian wrote:

In D48319#1102005, @bz wrote:

In D48319#1101982, @adrian wrote:

rofl nice catch, wanna land that too? :-)

The question is, should -vht also clear -vht40 -vht80 -vht160 -cht80p80?

It should just disable vht entirely, but it shouldn't need to clear ALL the flags.
The net80211 code should be checking if vht is enabled before checking the channel bandwidths avaliable.

I'm /pretty/ sure setting -ht doesn't also clear -ht40 greenfield, etc, it just disables being able to negotiate HT to begin with.

In D48319#1101982, @adrian wrote:

rofl nice catch, wanna land that too? :-)

In D48319#1101978, @adrian wrote:

That /does/ remind me, we should figure out why "ifconfig wlan0 -vht" doesn't work :-)

(ifconfig wlan0 -ht and ifconfig wlan0 ht works though!)

FYI for next time there is a USB group; feel free to add it or yourself to it if you are interested in USB.