Re: [RFC] nl80211: export frequencies/bitrates

[Johannes Berg <johannes@sipsolutions.net>]

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


> If you mean by "SET support" as for SET support for the regulatory
> domain struct then no, I need a few more. Here's a list of some:
> 
> * Power (EIRP, IR and for PtP or PtMP)
> * Antenna gain
> * Environment capabilities (Indoor/outdoor)
> * Modulation capabilities

Right. I haven't really considered any of those yet so yes, you'll have
to add them.

> Of these we can use to export more wiphy capabilities:  power (just
> IR), modulation capabilities, and antenna gain (we could assume ~dBi
> for antenna gain, and let user configure this).

Sure.

> Hmm -- not sure if rates should be an attribute of the band. In terms
> of IEEE-802.11 I would think we could add to the band IEEE-802.11
> "modes" (a, b, g or n), and each mode can have a set of modulations
> and each modulation a set of rates. This is from the wiphy device
> capability point of view.

Well, "modes" don't really make sense any more, ever since 11g and
especially with 11n it makes a lot more sense to specify what sort of
operation the hardware is capable which in which band (2.4 or 5 GHz).

> From the regulatory point of view I broke
> things down a bit differently -- a band can have set of subbands and a
> subband can have a set of possible modulations (flags). This is
> because regulatory laws usually speak about frequency ranges and on
> these ranges you usually have the same set of power/antenna
> restrictions. One thing we'll have to think about later is channel
> usage for 802.11n, haven't started toying with that yet in terms of
> regulatory restrictions but I think it may just be the list of
> channels (center of freqs) which can be used at the same time.

Right. So you're saying we should have sub-bands here? Do we really need
to have per-sub-band modulations rather than per-band as we do now?

> Should we have an nl80211_wiphy_band_attr and an
> nl80211_reg_band_attr? Or should we try to come up with just one which
> would work and make sense for both device capability and regulatory
> structure definition?

I think we should use just one. On the other hand, regulatory info is
only relevant temporally while hardware capabilities don't change.
Therefore, if there really need to be modulation restrictions a la "no
OFDM on channel 1 in Takatukaland" we could add a NO_OFDM flag to the
channel and use that to disable/enable OFDM rates whenever we change
channels...

> Is @NL80211_FREQUENCY_ATTR_CENTER_FREQ too long? If so then can we
> specify that its used for the center of freq in the kdoc comment?

Who's going to type it? :) I called it "center frequency" all through so
wanted to be consistent here.

johannes

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