From: Johannes Berg <johannes@sipsolutions.net> To: Seth Forshee <seth.forshee@canonical.com>, bkil <b.K.il.h.u+tigbuh@gmail.com> Cc: wireless-regdb@lists.infradead.org, linux-wireless@vger.kernel.org Subject: Re: [PATCH v2] wireless-regdb: recent FCC report and order allows 5850-5895 immediately Date: Mon, 09 Aug 2021 22:06:31 +0200 [thread overview] Message-ID: <1f441ba830535161b62086c1fee0d027b36bffc6.camel@sipsolutions.net> (raw) In-Reply-To: <YOdVFE51Wbxr80Qf@ubuntu-x1> Hi, Uh, sorry for the delay. > > The first is that it seems I forgot to test build this patch before I > pushed it. The PTMP-ONLY flag isn't allowed by db2fw.py. This was done > by Johannes for reasons which aren't explained, so maybe he can shed > some light on it. The flag doesn't appear to be used by the kernel or > hostapd, so maybe it was deprecated long ago. Anyway, I've pushed a > change to remove this flag. I don't remember, but quite likely we decided it was just not something we could implement properly or so, and never supported it? Sorry. Clearly the kernel does nothing at all with NL80211_RRF_PTMP_ONLY. > The second problem is more serious. I thought that we could allow 160 > MHz bandwidth across two AUTO-BW ranges too small for this bandwidth, > but it turns out that the kernel rejects any rules with a bandwidth > greater than the frequency range of the rule. I'm not sure what we can > do about this. Even if the kernel were changed to support allowing > greater bandwidths across combined ranges, we're going to have a > backwards compatibility problem with older kernels. OTOH, doesn't AUTO-BW basically ignore the max bandwidth for a given range anyway, seeing the code in reg_get_max_bandwidth_from_range()? So just keeping it at 80 with AUTO-BW would still result in 160 being usable? I think? johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes@sipsolutions.net> To: Seth Forshee <seth.forshee@canonical.com>, bkil <b.K.il.h.u+tigbuh@gmail.com> Cc: wireless-regdb@lists.infradead.org, linux-wireless@vger.kernel.org Subject: Re: [wireless-regdb] [PATCH v2] wireless-regdb: recent FCC report and order allows 5850-5895 immediately Date: Mon, 09 Aug 2021 22:06:31 +0200 [thread overview] Message-ID: <1f441ba830535161b62086c1fee0d027b36bffc6.camel@sipsolutions.net> (raw) In-Reply-To: <YOdVFE51Wbxr80Qf@ubuntu-x1> Hi, Uh, sorry for the delay. > > The first is that it seems I forgot to test build this patch before I > pushed it. The PTMP-ONLY flag isn't allowed by db2fw.py. This was done > by Johannes for reasons which aren't explained, so maybe he can shed > some light on it. The flag doesn't appear to be used by the kernel or > hostapd, so maybe it was deprecated long ago. Anyway, I've pushed a > change to remove this flag. I don't remember, but quite likely we decided it was just not something we could implement properly or so, and never supported it? Sorry. Clearly the kernel does nothing at all with NL80211_RRF_PTMP_ONLY. > The second problem is more serious. I thought that we could allow 160 > MHz bandwidth across two AUTO-BW ranges too small for this bandwidth, > but it turns out that the kernel rejects any rules with a bandwidth > greater than the frequency range of the rule. I'm not sure what we can > do about this. Even if the kernel were changed to support allowing > greater bandwidths across combined ranges, we're going to have a > backwards compatibility problem with older kernels. OTOH, doesn't AUTO-BW basically ignore the max bandwidth for a given range anyway, seeing the code in reg_get_max_bandwidth_from_range()? So just keeping it at 80 with AUTO-BW would still result in 160 being usable? I think? johannes _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb
next prev parent reply other threads:[~2021-08-09 20:06 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-03 22:40 [PATCH] wireless-regdb: recent FCC report and order allows 5850-5895 immediately bkil 2020-12-03 22:40 ` [wireless-regdb] " bkil 2020-12-04 15:11 ` Seth Forshee 2020-12-04 15:11 ` [wireless-regdb] " Seth Forshee 2020-12-05 20:24 ` b.K.il.h.u+tigbuh 2020-12-05 20:24 ` [wireless-regdb] " b.K.il.h.u+tigbuh 2020-12-07 4:32 ` Seth Forshee 2020-12-07 4:32 ` [wireless-regdb] " Seth Forshee 2020-12-07 10:10 ` b.K.il.h.u+tigbuh 2020-12-07 10:10 ` [wireless-regdb] " b.K.il.h.u+tigbuh 2020-12-07 13:54 ` Seth Forshee 2020-12-07 13:54 ` [wireless-regdb] " Seth Forshee 2021-06-08 15:47 ` Seth Forshee 2021-06-08 15:47 ` [wireless-regdb] " Seth Forshee 2021-06-30 15:17 ` b.K.il.h.u+tigbuh 2021-06-30 15:17 ` [wireless-regdb] " b.K.il.h.u+tigbuh 2021-06-30 16:03 ` [PATCH v2] " bkil 2021-06-30 16:03 ` [wireless-regdb] " bkil 2021-07-06 15:51 ` Seth Forshee 2021-07-06 15:51 ` [wireless-regdb] " Seth Forshee 2021-07-08 19:42 ` Seth Forshee 2021-07-08 19:42 ` [wireless-regdb] " Seth Forshee 2021-08-09 20:06 ` Johannes Berg [this message] 2021-08-09 20:06 ` Johannes Berg 2021-08-11 19:22 ` Seth Forshee 2021-08-11 19:22 ` Seth Forshee 2021-07-06 15:45 ` [PATCH] " Seth Forshee 2021-07-06 15:45 ` [wireless-regdb] " Seth Forshee
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1f441ba830535161b62086c1fee0d027b36bffc6.camel@sipsolutions.net \ --to=johannes@sipsolutions.net \ --cc=b.K.il.h.u+tigbuh@gmail.com \ --cc=linux-wireless@vger.kernel.org \ --cc=seth.forshee@canonical.com \ --cc=wireless-regdb@lists.infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.