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;
Message-ID: <33a46d12583b540a921f6ce96065c9a177bd044d.camel@sipsolutions.net>
Subject: Re: [PATCH v3 01/12] cfg80211: regulatory: extend regulatory
 support for S1G
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Kieran Frewen <kieran.frewen@morsemicro.com>
Cc:     linux-wireless@vger.kernel.org, quic_jjohnson@quicinc.com,
        kernel test robot <lkp@intel.com>
Date:   Tue, 06 Sep 2022 11:36:20 +0200
In-Reply-To: <20220906044812.7609-2-kieran.frewen@morsemicro.com>
References: <20220906044812.7609-1-kieran.frewen@morsemicro.com>
         <20220906044812.7609-2-kieran.frewen@morsemicro.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

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.
>=20

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