Making this an inline function for the point of making it a function seems hard to justify for single use code.
Can we at least keep it as a normal function in ioctl.c?

Landed via another review (https://reviews.freebsd.org/D49161)

I've been working in this in another stack (https://reviews.freebsd.org/D58384 as an example) to do a lot of needed API cleanup before we can bump this without breaking the current ioctls.

oh damn i missed this, I think it's worth refactoring it so we do have a specific place to pull the TX power from.

Since it is also part of the VHT code path we can't just /not/ do it here; I think we need to handle NULL IE pointers in ieee80211_ht_updateparams_final() and just not do the htinfo deferefence there. (And document that the function must handle NULL IEs.)
Would you like to try that instead?

@adrian It's a (pretty terrible) AP from Huawei

In D58020#1330655, @adrian wrote:

ugh ok why's do_ht being set when there's no htcap/htinfo fields.

OH, hilarious, it's because you have VHT parameters but not HT parameters? That's problematic. Would you mind doing an "ifconfig -v wlan0 list scan" to capture what's being seen in the scan, find the entry that has VHT parameters and not HT parameters, and including it in here?

ugh ok why's do_ht being set when there's no htcap/htinfo fields.

For now I'd like to stay close to the original implementation and only extend the diagnostic where necessary.

In D57762#1327751, @nagymas_gmail.com wrote:

I personally I would go with the simpler solution calling IEEE80211_IS_CHAN_VHTxxx macros already combines mode and width.

static const char *
net80211_get_chanmode_descr(const struct ieee80211_channel *c)
{

...
<VHT*>

I personally I would go with the simpler solution calling IEEE80211_IS_CHAN_VHTxxx macros already combines mode and width.

In D57762#1327568, @adrian wrote:

I think we should just create a function to return a static channel description for this. something like

/*
 * Return a string like <MODE><WIDTH> - eg HT20, VHT80+80, etc.
 */
static const char * net80211_get_chanmode_descr(const struct ieee80211_channel *c)
{
  // do all the HT/VHT stuff currently done in the above log code
 // default
  return "<undef>";
}

What do you think?

I think we should just create a function to return a static channel description for this. something like

Reverted back to the original branching to keep the original structure. %s%d canged to %s%s to hande 80P80

Test HT20, HT40, VHT20, VHT40, VHT80, VHT160 not tested VHT80P80

Debug string update to be able to display VHT40U and VHT40D

Original reporting:
VHT80
VHT160
VHT (covers VHT20/VHT40)
Updated reporting:
VHT20
VHT40U
VHT40D
VHT80
VHT160
VHT80P80
Reason:
ni->ni_chan->ic_flags already contains the full channel-width information, so the patch makes the debug output reflect the actual negotiated channel state.

Added every configuration currently available for more accurate debuging

Agreed but we could detail VHT40U and D and VHT20 too

If we do it then let us do better than AI and also document 80P80.

ok, this is the next thing to dig into and figure out how to land.

You can eject the usb via software, that will init a reset.

interesting, is there no way to force a firmware reload without just power cycling the device?
eg if i wanted to test two different firmware images by unloading and reloading the driver?

landed, i fixed it locally