> 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:
signature.asc
Description: This is a digitally signed message part
