On Tue, Sep 6, 2022 at 9:36 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 2022-09-06 at 16:48 +1200, Kieran Frewen wrote: > > Extend the S1G regulatory information to support all regulatory > > domains. An reg_s1g.h file is included containing structs with key > > regulatory class information. These structs were required to ensure > > the right combination of information was available to a series of > > functions which support the mapping between frequencies, bandwidths, > > and channels. > > > > Hm. Isn't this type of thing something we'd usually want to keep in the > regulatory database to be able to update it? Who says JP will always > stick to their restrictive scheme, for example. > > johannes Yes I agree that this information would be best stored in the regulatory database. Especially in respect to maintaining a single up-to-date source of knowledge. I have done a bit of investigation into what information we would require in order to maintain the same level of functionality. I think at the very least we would have to add the base frequency to what already exists in the regulatory database. By adding this we would maintain the ability to map from S1G channels to frequencies. We would, however, lose the ability to specify exact bandwidths for a certain frequency as is the current behaviour in reg_rule_to_chan_bw_flags() and would likely have to change the S1G bandwidth flags to not permit certain bandwidths on a channel, e.g. IEEE80211_CHAN_NO_2MHZ as opposed to flagging a single allowed bandwidth. I do wonder that if we do add a base frequency to the regulatory database are we straying from just maintaining information which permits or prevents operation in a regulatory domain for a specific frequency and starting to include information that the kernel is relying on for mapping from one field to another, e.g. ieee80211_channel_to_freq_khz(). Kieran
