Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220906044812.7609-1-kieran.frewen@morsemicro.com>
 <20220906044812.7609-2-kieran.frewen@morsemicro.com> <33a46d12583b540a921f6ce96065c9a177bd044d.camel@sipsolutions.net>
In-Reply-To: <33a46d12583b540a921f6ce96065c9a177bd044d.camel@sipsolutions.net>
From:   Kieran Frewen <kieran.frewen@morsemicro.com>
Date:   Thu, 22 Sep 2022 10:10:51 +1200
Message-ID: <CAKHj3qTuYn344Z8Lvvc2gOvbrdkXxdy6a2UXjPv9MGbP8n1qKQ@mail.gmail.com>
Subject: Re: [PATCH v3 01/12] cfg80211: regulatory: extend regulatory support
 for S1G
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org, quic_jjohnson@quicinc.com,
        kernel test robot <lkp@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Sep 6, 2022 at 9:36 PM Johannes Berg <johannes@sipsolutions.net> 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