Bug 178263 - [ath] review the use of ic_freq / ic_ieee / ic_flags / ichan->channel
Summary: [ath] review the use of ic_freq / ic_ieee / ic_flags / ichan->channel
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
Depends on:
Reported: 2013-04-30 17:20 UTC by Adrian Chadd
Modified: 2018-05-28 19:46 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2013-04-30 17:20:00 UTC
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.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-04-30 18:13:29 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:40 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

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.