> > - struct ieee80211_channel: > > use (phymode, channel, 80211n-mode) as "key"; kill off frequency > > (which will move to some get_channel_foobar function) > > Hmm. Maybe we should've kept frequency. How do we want to handle > dot11ChannelStartingFactor (see 17.3.8.3.2 Channel numbering in > 802.11j), I quote: > > Change the text of 17.3.8.3.2 as follows: > Channel center frequencies are defined at every integral multiple of 5 MHz above Channel starting > frequency. The relationship between center frequency and channel number is given by Equation (27): > > Channel center frequency = Channel starting frequency + (nch × 5) (MHz) (27) > (nl80211 part:) Well, I would handle it exactly like that. Keep channel numbers, add channel starting frequency as configurable (regulatory?) parameter for the device. The mapping between channel numbers an frequencies, while for most cases fixed, can't be assumed to be so under all circumstances. Applications should use CMD_GET_CHANLIST to get a list of stuff supported. If the device is configured to use 11j 4.9GHz band, that list might for example contain: mode=80211A channel=184 # frequency=4920 mode=80211A10 channel=184 # frequency=4920 mode=80211A10 channel=186 # frequency=4930 (no idea whether that channel exists, example pulled from hot air using channel start = 4000M) (cfg80211 part:) Now the real question is how to handle that inside the kernel... you're right, unless we introduce a channel_to_freq function which takes both the channel structure *and* the base frequency as parameters, we need to have the frequency in struct ieee80211_channel. Anyone feel like elaborating (dis)advantages of those two? Drivers might actually be setting their RF using the channel value, having a non-matching freq might confuse things... OTOH, having the final frequency is nice too... this requires some thought :/. ... since for most devices there is a fixed (phymode)->(channel_start) mapping, I'm tempted to say "have channel_start be a mode parameter" for now. Anyway, 802.11j needs configurable channel *width* too (10M/20M). I'd add it as "80211A10" phymode; that wouldn't require any new API or stuff. And for setting the channel starting frequency, the regulatory API might both make sense and be the closest thing related. (btw, I think we should multicast NL80211_CMD_NEW_CHANLIST notifications on regulatory updates). -David P.S.: Just for fun, we could actually have the set_channel part work on 802.16 (WiMAX) devices too :) - we only need to return an appropriate channel list, define a phymode value and *poof* universal channel switcher :) P.P.S.: Just joking. - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
