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

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?

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