>Number: 178263 >Category: kern >Synopsis: [ath] review the use of ic_freq / ic_ieee / ic_flags / >ichan->channel >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Apr 30 16:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: -HEAD >Organization: >Environment: n/a >Description: 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. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
