The IEEE80211_KEYBUF_SIZE and IEEE80211_MICBUF_SIZE are sprinkled
throughout the net80211 stack, ioctl API and drivers. This makes it
challenging to (eventually) up IEEE80211_KEYBUF_SIZE to support 256 /
384 bit encryption as, well, it'll break every single driver and the
ioctl API in doing so.
So as part of this, let's start to separate out the current key/mic
buffer size from what drivers and the ioctl layer are using.
Drivers especially shouldn't be using these definitions as their
key sizes are hardware / firmware API limits, not net80211 limits.
Ideally drivers would define their own key buffer / mic buffer
sizes and only copy in keys up to that length (and fail keys
that are too large) but the current net80211 API isn't there yet.
This doesn't yet change what defines / buffer sizes are used in the
ioctl layer. I'm going to plan out some subsequent work to
separate out those defines and ioctl APIs so they maintain using
the 128 bit key/mic buffer sizes and will copy them in/out of any
larger net80211 key buffer size in the future.