Mode/Channel/Bitrate API

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

Hey,

So many people seem to agree that the capability registering in mac80211
is somewhat awkward to use. Also, it doesn't really match how hardware
works with the separation of B and G mode.

I've been thinking about this for a while and would like to get your
input on the following replacement API.

First, I think we should completely get rid of the mode stuff. This is
an artificial distinction between hardware supports operating in
frequency bands, not in modes, and the actual mode differences are
controlled differently.

Hence, what I'm thinking is that

 (a) the driver registers which channel center frequencies it can
     operate with, it could in theory just be a range (e.g. 2400-2500
     MHz) or more practically be list of center frequencies. Just
     contains frequencies and possibly hardware dependent values for the
     frequency. This is done in "bands", something like
     FREQUENCY_BAND_2_4GHZ and FREQUENCY_BAND_5GHZ, "bands" replace the
     current "modes".
 (b) additionally, the driver registers as flags
     - whether it can support G mode short slot operation
     - whether it can receive B mode short barker preambles
     (both of which are only relevant if it supports 2.4 GHz operation)
 (c) for each registered band, the driver registers which bitrates the
     hw supports. this implicitly defines the modulation too.
 (d) now, selecting a channel by frequency is unique, but we need to
     give new options to select short slot, short preamble and allowed
     bitrates. For client mode, these are initialised to what the AP
     supports and you can't for example turn off short slot when the AP
     requires it; for AP mode it's initialised to what the HW supports
     but if you want less you can select that. Rate control algorithms
     need to take into account this as well similar to what they already
     do.

Does anyone see problems with this? I think it matches hardware much
better than the current scheme where B and G mode almost totally
overlap. Also, right now we only advertise short preamble for when we
have G mode support which is wrong since short preamble was an optional
feature of 11B, currently 11B hardware that supports short preambles
will never be able to associate to an AP that requires it with mac80211.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]