Review the use of the frequency / channel fields in ieee80211_channel and HAL_CHANNEL_INTERNAL. * check whether net80211's ieee80211_channel entry stores the real frequency (eg 900mhz, 420mhz mapping) or the underlying channel frequency; * .. and whether ic_flags shows a 900MHz channel using 2.4GHz hardware as being a 2.4GHz channel; * .. and whether ic_ieee reflects the 900MHz IEEE number, or the 2.4GHz hardware number. * Evaluate what HAL_CHANNEL_INTERNAL gets - I _think_ it gets the real channel frequency in 'channel', but we don't store the real channel IEEE number. The aim is to correctly support channel mapping for the 11n chips. I'm worried that ic_freq / ic_flags / ic_ieee is used in places where it shouldn't be. It's also a big requirement to get channel mapping 'right' on the AR9380 and later hardware, in case some vendors (eg Ubiquiti) decide to glue downconverters on the newer chips. It's possible that I'll have to extend the HAL to include this information in HAL_CHANNEL_INTERNAL and then modify a bunch of code to use HAL_CHANNEL_INTERNAL instead of ieee80211_channel when looking at what the _hardware_ programming should look like.
Responsible Changed From-To: freebsd-bugs->freebsd-wireless Over to maintainer(s).
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.