[PATCH v2 0/3] Channels in licensed bands, noise floor override

[PATCH v2 0/3] Channels in licensed bands, noise floor override

[Simon Wunderlich]

This is the revised series for adding channels in licensed bands and the
noise floor override. Thanks for the previous discussions, I've adopted
suggestions from Zefir and Sebastian accordingly and rebased the series.

For more background info, please check the v1 series:

https://www.spinics.net/lists/linux-wireless/msg160266.html

Cheers,
     Simon
 
Ben Greear (1):
  ath9k: Support channels in licensed bands

Simon Wunderlich (2):
  ath10k: add support for channels in licensed bands
  ath9k: add noise floor override option

 drivers/net/wireless/ath/ath10k/Kconfig      | 20 +++++++++
 drivers/net/wireless/ath/ath10k/core.h       |  4 ++
 drivers/net/wireless/ath/ath10k/mac.c        | 10 +++++
 drivers/net/wireless/ath/ath10k/wmi.c        | 53 +++++++++++++++++-------
 drivers/net/wireless/ath/ath9k/Kconfig       | 20 +++++++++
 drivers/net/wireless/ath/ath9k/calib.c       |  5 ++-
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++++++
 drivers/net/wireless/ath/ath9k/debug.c       | 62 ++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/hw.h          |  5 +++
 9 files changed, 177 insertions(+), 17 deletions(-)

-- 
2.11.0

[PATCH v2 0/3] Channels in licensed bands, noise floor override

[Simon Wunderlich]

This is the revised series for adding channels in licensed bands and the
noise floor override. Thanks for the previous discussions, I've adopted
suggestions from Zefir and Sebastian accordingly and rebased the series.

For more background info, please check the v1 series:

https://www.spinics.net/lists/linux-wireless/msg160266.html

Cheers,
     Simon
 
Ben Greear (1):
  ath9k: Support channels in licensed bands

Simon Wunderlich (2):
  ath10k: add support for channels in licensed bands
  ath9k: add noise floor override option

 drivers/net/wireless/ath/ath10k/Kconfig      | 20 +++++++++
 drivers/net/wireless/ath/ath10k/core.h       |  4 ++
 drivers/net/wireless/ath/ath10k/mac.c        | 10 +++++
 drivers/net/wireless/ath/ath10k/wmi.c        | 53 +++++++++++++++++-------
 drivers/net/wireless/ath/ath9k/Kconfig       | 20 +++++++++
 drivers/net/wireless/ath/ath9k/calib.c       |  5 ++-
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++++++
 drivers/net/wireless/ath/ath9k/debug.c       | 62 ++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/hw.h          |  5 +++
 9 files changed, 177 insertions(+), 17 deletions(-)

-- 
2.11.0


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

From: Ben Greear <greearb@candelatech.com>

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Ben Greear <greearb@candelatech.com>
[Hide this support behind a Kconfig option]
Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
[only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, simplify]
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
---
Changes to PATCHv1:
 * fix bug reported by Zefir, and simplify patch more
---
 drivers/net/wireless/ath/ath9k/Kconfig       | 20 ++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++++++++++++++
 drivers/net/wireless/ath/ath9k/hw.h          |  4 ++++
 3 files changed, 39 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f1a626..23b8abf4449a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED
 	  developed. At this point enabling this option won't do anything
 	  except increase code size.
 
+config ATH9K_LICENSED_CHAN
+	bool "Support channels in licensed bands"
+	depends on ATH9K && CFG80211_CERTIFICATION_ONUS
+	default n
+	---help---
+	  This option enables support for licensed channels on such as
+          4.9 GHz (public safety).
+
+	  These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+	  regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+	  your local radio regulator, e.g. the FCC or equivalent. Using these
+	  channels without proper authorisation may result in serious legal
+	  consequences.
+
+	  You will also have to build a regulatory database with these channels
+	  enabled to actually use them.
+
+	  If you are a distro kernel builder or have any doubt whatsoever about
+	  your legal ability to use these channels, say N.
+
 config ATH9K_DYNACK
 	bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
 	depends on ATH9K
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c
index 8b4f7fdabf58..3d65dce13048 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,21 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = {
 	CHAN5G(5785, 35), /* Channel 157 */
 	CHAN5G(5805, 36), /* Channel 161 */
 	CHAN5G(5825, 37), /* Channel 165 */
+
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+	/* 4.9Ghz channels, public safety channels, license is required in US
+	 * and most other regulatory domains!
+	 */
+	/* 802.11j 4.9 GHz (20 MHz) */
+	CHAN5G(4920, 38), /* channel 184 */
+	CHAN5G(4940, 39), /* channel 188 */
+	CHAN5G(4960, 40), /* channel 192 */
+	CHAN5G(4980, 41), /* channel 196 */
+	/* 802.11j 5.030 - 5.080 GHz (20 MHz) */
+	CHAN5G(5040, 42), /* channel 8 */
+	CHAN5G(5060, 43), /* channel 12 */
+	CHAN5G(5080, 44), /* channel 16 */
+#endif
 };
 
 /* Atheros hardware rate code addition for short premble */
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 9cbca1229bac..2166f644599d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -73,7 +73,11 @@
 
 #define ATH9K_RSSI_BAD			-128
 
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+#define ATH9K_NUM_CHANNELS	45
+#else
 #define ATH9K_NUM_CHANNELS	38
+#endif
 
 /* Register read/write primitives */
 #define REG_WRITE(_ah, _reg, _val) \
-- 
2.11.0

[PATCH v2 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

From: Ben Greear <greearb@candelatech.com>

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Ben Greear <greearb@candelatech.com>
[Hide this support behind a Kconfig option]
Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
[only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, simplify]
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
---
Changes to PATCHv1:
 * fix bug reported by Zefir, and simplify patch more
---
 drivers/net/wireless/ath/ath9k/Kconfig       | 20 ++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++++++++++++++
 drivers/net/wireless/ath/ath9k/hw.h          |  4 ++++
 3 files changed, 39 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f1a626..23b8abf4449a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED
 	  developed. At this point enabling this option won't do anything
 	  except increase code size.
 
+config ATH9K_LICENSED_CHAN
+	bool "Support channels in licensed bands"
+	depends on ATH9K && CFG80211_CERTIFICATION_ONUS
+	default n
+	---help---
+	  This option enables support for licensed channels on such as
+          4.9 GHz (public safety).
+
+	  These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+	  regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+	  your local radio regulator, e.g. the FCC or equivalent. Using these
+	  channels without proper authorisation may result in serious legal
+	  consequences.
+
+	  You will also have to build a regulatory database with these channels
+	  enabled to actually use them.
+
+	  If you are a distro kernel builder or have any doubt whatsoever about
+	  your legal ability to use these channels, say N.
+
 config ATH9K_DYNACK
 	bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
 	depends on ATH9K
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c b/drivers/net/wireless/ath/ath9k/common-init.c
index 8b4f7fdabf58..3d65dce13048 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,21 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] = {
 	CHAN5G(5785, 35), /* Channel 157 */
 	CHAN5G(5805, 36), /* Channel 161 */
 	CHAN5G(5825, 37), /* Channel 165 */
+
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+	/* 4.9Ghz channels, public safety channels, license is required in US
+	 * and most other regulatory domains!
+	 */
+	/* 802.11j 4.9 GHz (20 MHz) */
+	CHAN5G(4920, 38), /* channel 184 */
+	CHAN5G(4940, 39), /* channel 188 */
+	CHAN5G(4960, 40), /* channel 192 */
+	CHAN5G(4980, 41), /* channel 196 */
+	/* 802.11j 5.030 - 5.080 GHz (20 MHz) */
+	CHAN5G(5040, 42), /* channel 8 */
+	CHAN5G(5060, 43), /* channel 12 */
+	CHAN5G(5080, 44), /* channel 16 */
+#endif
 };
 
 /* Atheros hardware rate code addition for short premble */
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 9cbca1229bac..2166f644599d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -73,7 +73,11 @@
 
 #define ATH9K_RSSI_BAD			-128
 
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+#define ATH9K_NUM_CHANNELS	45
+#else
 #define ATH9K_NUM_CHANNELS	38
+#endif
 
 /* Register read/write primitives */
 #define REG_WRITE(_ah, _reg, _val) \
-- 
2.11.0


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Kalle Valo]

Simon Wunderlich <sw@simonwunderlich.de> wrote:
> From: Ben Greear <greearb@candelatech.com>
> 
> Many chips support channels in licensed bands. Add support for those,
> along with a corresponding kernel config option to disable them by
> default. Note that these channels are not selectable even if the
> option has been compiled unless the user modifies the regulatory
> database to explicitly enable the corresponding channels.
> 
> NOTE:  These channels must not be used in most regulatory
> domains unless you have a license from the FCC or similar!
> 
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> [Hide this support behind a Kconfig option]
> Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
> [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, simplify]
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>

I am not sure that we should support unlicensed bands in Linux and hence
hesitant to apply these. My view is that due to regulatory restrictions we
should not make it too easy to use unlicensed bands. But I'm open for
discussion, this is a challenging area and my knowledge here is limited.

-- 
https://patchwork.kernel.org/patch/9641105/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Kalle Valo]

Simon Wunderlich <sw@simonwunderlich.de> wrote:
> From: Ben Greear <greearb@candelatech.com>
> 
> Many chips support channels in licensed bands. Add support for those,
> along with a corresponding kernel config option to disable them by
> default. Note that these channels are not selectable even if the
> option has been compiled unless the user modifies the regulatory
> database to explicitly enable the corresponding channels.
> 
> NOTE:  These channels must not be used in most regulatory
> domains unless you have a license from the FCC or similar!
> 
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> [Hide this support behind a Kconfig option]
> Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
> [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, simplify]
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>

I am not sure that we should support unlicensed bands in Linux and hence
hesitant to apply these. My view is that due to regulatory restrictions we
should not make it too easy to use unlicensed bands. But I'm open for
discussion, this is a challenging area and my knowledge here is limited.

-- 
https://patchwork.kernel.org/patch/9641105/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Hi,

On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> Simon Wunderlich <sw@simonwunderlich.de> wrote:
> > From: Ben Greear <greearb@candelatech.com>
> > 
> > Many chips support channels in licensed bands. Add support for those,
> > along with a corresponding kernel config option to disable them by
> > default. Note that these channels are not selectable even if the
> > option has been compiled unless the user modifies the regulatory
> > database to explicitly enable the corresponding channels.
> > 
> > NOTE:  These channels must not be used in most regulatory
> > domains unless you have a license from the FCC or similar!
> > 
> > Signed-off-by: Ben Greear <greearb@candelatech.com>
> > [Hide this support behind a Kconfig option]
> > Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
> > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed
> > bands, simplify] Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> > Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
> 
> I am not sure that we should support unlicensed bands in Linux and hence
> hesitant to apply these. My view is that due to regulatory restrictions we
> should not make it too easy to use unlicensed bands. But I'm open for
> discussion, this is a challenging area and my knowledge here is limited.

thanks for your reply! I agree that we should not make it too easy, and 
therefore there are the following "obstacles" which should avoid accidental 
use of license bands:

 * we have the kernel CONFIG option which features a big fat warning
 * regulatory database must be tampered with to enabel the channels. In 
distributions, the regdb also gets signed. There is also the "internal regdb" 
CONFIG option if you compile your own kernel (rarely used, except for 
OpenWRT). In each case, a user must actively add the 4.9 GHz channels into it, 
because they are not included in the default regdb (and this should not 
change).
 * CFG80211_CERTIFICATION_ONUS is also required, which also says "you are on 
your own".

I had a comparison with ath5k, which also allows using those channels without 
at least the special configuration option (there is one enabling even more 
channels). The regdb "obstacle" is in place as well. However, ath5k is for 
very old chips and therefore the threat is limited.

In my personal view, we have quite a few obstacles which I consider "enough", 
but would be interesting to hear others opinions ...

Cheers,
      Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

[-- Attachment #1.1: Type: text/plain, Size: 2496 bytes --]

Hi,

On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> Simon Wunderlich <sw@simonwunderlich.de> wrote:
> > From: Ben Greear <greearb@candelatech.com>
> > 
> > Many chips support channels in licensed bands. Add support for those,
> > along with a corresponding kernel config option to disable them by
> > default. Note that these channels are not selectable even if the
> > option has been compiled unless the user modifies the regulatory
> > database to explicitly enable the corresponding channels.
> > 
> > NOTE:  These channels must not be used in most regulatory
> > domains unless you have a license from the FCC or similar!
> > 
> > Signed-off-by: Ben Greear <greearb@candelatech.com>
> > [Hide this support behind a Kconfig option]
> > Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
> > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed
> > bands, simplify] Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> > Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
> 
> I am not sure that we should support unlicensed bands in Linux and hence
> hesitant to apply these. My view is that due to regulatory restrictions we
> should not make it too easy to use unlicensed bands. But I'm open for
> discussion, this is a challenging area and my knowledge here is limited.

thanks for your reply! I agree that we should not make it too easy, and 
therefore there are the following "obstacles" which should avoid accidental 
use of license bands:

 * we have the kernel CONFIG option which features a big fat warning
 * regulatory database must be tampered with to enabel the channels. In 
distributions, the regdb also gets signed. There is also the "internal regdb" 
CONFIG option if you compile your own kernel (rarely used, except for 
OpenWRT). In each case, a user must actively add the 4.9 GHz channels into it, 
because they are not included in the default regdb (and this should not 
change).
 * CFG80211_CERTIFICATION_ONUS is also required, which also says "you are on 
your own".

I had a comparison with ath5k, which also allows using those channels without 
at least the special configuration option (there is one enabling even more 
channels). The regdb "obstacle" is in place as well. However, ath5k is for 
very old chips and therefore the threat is limited.

In my personal view, we have quite a few obstacles which I consider "enough", 
but would be interesting to hear others opinions ...

Cheers,
      Simon

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Steve deRosier]

Hi,

(sorry, resending due to my not noticing that gmail had changed my
default compose mode to HTML. Why does it randomly do that
sometimes?!?!)

On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <sw@simonwunderlich.de> wrote:
>
> Hi,
>
> On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> > Simon Wunderlich <sw@simonwunderlich.de> wrote:
> > > From: Ben Greear <greearb@candelatech.com>
> > >
> > > Many chips support channels in licensed bands. Add support for those,
> > > along with a corresponding kernel config option to disable them by

...

> > I am not sure that we should support unlicensed bands in Linux and hence
> > hesitant to apply these. My view is that due to regulatory restrictions we
> > should not make it too easy to use unlicensed bands. But I'm open for
> > discussion, this is a challenging area and my knowledge here is limited.
>
...
>
>
> In my personal view, we have quite a few obstacles which I consider "enough",
> but would be interesting to hear others opinions ...
>

I'll throw in my 2-cents. This patch is treading on very dangerous
ground. I can't speak to other regulatory environments, but at least
the FCC is cracking down on even the possibility that anyone can
operate a WiFi device outside the regulatory bounds.

I know this is going to be TLDR, but please bear with me.

The testing groups are (incorrectly in my opinion) interpreting the
current FCC guidelines to be that no one with the device could ever
get in and change it to operate outside the permitted frequencies and
powers. And I'm not even talking about having a command-line interface
and issuing a command as sudo. To the degree that if it's even
possible to recompile a driver or otherwise change the source code and
put that changed code on the device they're denying modular
certifications.

The end result is we have a lot of chip manufacturers' scrambling to
do things like require eeproms, signed board files, etc. Module
manufacturers (think of things like Laird's msd45nbt, msd50nbt, or the
Sterling LWB) are scrambling even harder trying to think of ways to
force chips to fail to function if they aren't using their regulatory
file or other strategies to manage to fulfill their customer's needs
while still getting it to pass through the regulatory agencies.

@Simon, with much respect: With the current regulatory environment,
those obstacles which you are considering "enough", the testing boards
aren't considering "enough".

I happen to agree with you that it's more than enough. And just
because it's possible for a customer of a module who is integrating a
device to operate it out of the regulatory bounds, doesn't mean it
shouldn't get the modular certification. In fact, depending on the
exact situations, it might be _necessary_ for them to make setting
adjustments for their products. And the reality is, anyone with a
soldering iron can make the thing operate outside the regulatory
domain anyway. The whole thing just makes it impossible for modular
operators and for the Linux community instead of solving any real
problems.

What's going on in the FCC regulatory environment has stark
implications that those of us in the Linux wireless community can't
afford to ignore anymore. This is a direct threat to mac80211, Open
Source and the ability to do anything sane with our devices. And even
if you're more practical (like me) about these things, think of it:
each manufacturer being forced to make it harder and harder for anyone
to change the code or work with their chips - you think it's hard to
work with a Marvell or Broadcom chip right now with minimal and
non-accessible documentation? Imagine how it's going to be when
everything is locked behind Secure Boot and signed proprietary drivers
where the hardware itself is locked so it can only work with the (bad
quality and buggy) closed-source driver.

I brought this up at Wireless Summit at the last LPC and basically got
a room of shrugs. Admittedly I wasn't terribly eloquent on the subject
so it's solely my fault I didn't impress. I know that most of us are
representing various companies (though not I anymore) and each has
their own proprietary way to deal with it and no one wants to rock the
boat*. And many of the people in the room are just implementing code
to make stuff work and don't actually know that much depth about the
regulatory environment in which we're working. But we all need to get
together and come up with a better solution.

What's going on right now doesn't serve our interests. I know it's an
agenda being pushed by someone and while I have a few suspects I
really don't know for sure. In any case, who it's being pushed by and
for doesn't matter too much - we as a community aren't pushing back as
a cohesive group; we aren't even talking about it! And so, we're going
to get the short end of the stick.

So, with re: to the patch, that's the environment it will live in.
Personally I don't really care one way or another specifically to what
Simon's patch does. But he opened the door to discussion and it seemed
like an appropriate opportunity. I don't mind that it opens more
functionality, functionality that the chip in question supports. I'd
even regard this as a good thing, especially considering the
"obstacles" in place. And keeping it out doesn't solve anything to do
with the root of the problem either.

As for merging it, I guess my only test would be: is this a
functionality that the community as a whole benefits from? Either
because more than one person would be using it, or we have a vested
interest in keeping a cohesive codebase that doesn't require people to
use it a crazy maintenance overhead by requiring patching every time
they upgrade? But that's always the same questions with any patch.

In either case, patch merged or not: we still have an important
discussion to have about what we're going to do about the FCC
regulatory problems - before someone "solves" it for us in a way that
hurts us all.

If you got this far, thanks for reading this.

Thanks,
- Steve


footnote:
* Personally, I think that many of the devices in the past and
currently are getting certifications by clever wording on the
documents and getting through on a wink and a nod. And no one wants to
talk about it because that means acknowledging that fact and risking
newer devices having a more difficult time getting through.

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Steve deRosier]

Hi,

(sorry, resending due to my not noticing that gmail had changed my
default compose mode to HTML. Why does it randomly do that
sometimes?!?!)

On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <sw@simonwunderlich.de> wrote:
>
> Hi,
>
> On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> > Simon Wunderlich <sw@simonwunderlich.de> wrote:
> > > From: Ben Greear <greearb@candelatech.com>
> > >
> > > Many chips support channels in licensed bands. Add support for those,
> > > along with a corresponding kernel config option to disable them by

...

> > I am not sure that we should support unlicensed bands in Linux and hence
> > hesitant to apply these. My view is that due to regulatory restrictions we
> > should not make it too easy to use unlicensed bands. But I'm open for
> > discussion, this is a challenging area and my knowledge here is limited.
>
...
>
>
> In my personal view, we have quite a few obstacles which I consider "enough",
> but would be interesting to hear others opinions ...
>

I'll throw in my 2-cents. This patch is treading on very dangerous
ground. I can't speak to other regulatory environments, but at least
the FCC is cracking down on even the possibility that anyone can
operate a WiFi device outside the regulatory bounds.

I know this is going to be TLDR, but please bear with me.

The testing groups are (incorrectly in my opinion) interpreting the
current FCC guidelines to be that no one with the device could ever
get in and change it to operate outside the permitted frequencies and
powers. And I'm not even talking about having a command-line interface
and issuing a command as sudo. To the degree that if it's even
possible to recompile a driver or otherwise change the source code and
put that changed code on the device they're denying modular
certifications.

The end result is we have a lot of chip manufacturers' scrambling to
do things like require eeproms, signed board files, etc. Module
manufacturers (think of things like Laird's msd45nbt, msd50nbt, or the
Sterling LWB) are scrambling even harder trying to think of ways to
force chips to fail to function if they aren't using their regulatory
file or other strategies to manage to fulfill their customer's needs
while still getting it to pass through the regulatory agencies.

@Simon, with much respect: With the current regulatory environment,
those obstacles which you are considering "enough", the testing boards
aren't considering "enough".

I happen to agree with you that it's more than enough. And just
because it's possible for a customer of a module who is integrating a
device to operate it out of the regulatory bounds, doesn't mean it
shouldn't get the modular certification. In fact, depending on the
exact situations, it might be _necessary_ for them to make setting
adjustments for their products. And the reality is, anyone with a
soldering iron can make the thing operate outside the regulatory
domain anyway. The whole thing just makes it impossible for modular
operators and for the Linux community instead of solving any real
problems.

What's going on in the FCC regulatory environment has stark
implications that those of us in the Linux wireless community can't
afford to ignore anymore. This is a direct threat to mac80211, Open
Source and the ability to do anything sane with our devices. And even
if you're more practical (like me) about these things, think of it:
each manufacturer being forced to make it harder and harder for anyone
to change the code or work with their chips - you think it's hard to
work with a Marvell or Broadcom chip right now with minimal and
non-accessible documentation? Imagine how it's going to be when
everything is locked behind Secure Boot and signed proprietary drivers
where the hardware itself is locked so it can only work with the (bad
quality and buggy) closed-source driver.

I brought this up at Wireless Summit at the last LPC and basically got
a room of shrugs. Admittedly I wasn't terribly eloquent on the subject
so it's solely my fault I didn't impress. I know that most of us are
representing various companies (though not I anymore) and each has
their own proprietary way to deal with it and no one wants to rock the
boat*. And many of the people in the room are just implementing code
to make stuff work and don't actually know that much depth about the
regulatory environment in which we're working. But we all need to get
together and come up with a better solution.

What's going on right now doesn't serve our interests. I know it's an
agenda being pushed by someone and while I have a few suspects I
really don't know for sure. In any case, who it's being pushed by and
for doesn't matter too much - we as a community aren't pushing back as
a cohesive group; we aren't even talking about it! And so, we're going
to get the short end of the stick.

So, with re: to the patch, that's the environment it will live in.
Personally I don't really care one way or another specifically to what
Simon's patch does. But he opened the door to discussion and it seemed
like an appropriate opportunity. I don't mind that it opens more
functionality, functionality that the chip in question supports. I'd
even regard this as a good thing, especially considering the
"obstacles" in place. And keeping it out doesn't solve anything to do
with the root of the problem either.

As for merging it, I guess my only test would be: is this a
functionality that the community as a whole benefits from? Either
because more than one person would be using it, or we have a vested
interest in keeping a cohesive codebase that doesn't require people to
use it a crazy maintenance overhead by requiring patching every time
they upgrade? But that's always the same questions with any patch.

In either case, patch merged or not: we still have an important
discussion to have about what we're going to do about the FCC
regulatory problems - before someone "solves" it for us in a way that
hurts us all.

If you got this far, thanks for reading this.

Thanks,
- Steve


footnote:
* Personally, I think that many of the devices in the past and
currently are getting certifications by clever wording on the
documents and getting through on a wink and a nod. And no one wants to
talk about it because that means acknowledging that fact and risking
newer devices having a more difficult time getting through.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 04/18/2017 09:33 AM, Steve deRosier wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <sw@simonwunderlich.de <mailto:sw@simonwunderlich.de>> wrote:
>
>     Hi,
>
>     On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
>     > Simon Wunderlich <sw@simonwunderlich.de <mailto:sw@simonwunderlich.de>> wrote:
>     > > From: Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
>     > >
>     > > Many chips support channels in licensed bands. Add support for those,
>     > > along with a corresponding kernel config option to disable them by
>
> ...
>
>     > I am not sure that we should support unlicensed bands in Linux and hence
>     > hesitant to apply these. My view is that due to regulatory restrictions we
>     > should not make it too easy to use unlicensed bands. But I'm open for
>     > discussion, this is a challenging area and my knowledge here is limited.
>
> ...
>
>
>     In my personal view, we have quite a few obstacles which I consider "enough",
>     but would be interesting to hear others opinions ...
>
>
> I'll throw in my 2-cents. This patch is treading on very dangerous ground. I can't speak to other regulatory environments, but at least the FCC is cracking down
> on even the possibility that anyone can operate a WiFi device outside the regulatory bounds.

These patches make it slightly easier to use the licensed bands, but no one
can accidentally use them due to the regdb and other constaints in these
patches.

So, I don't think these patches offer any fundamental new vulnerability
that should concern the FCC.

After all, someone who really wants to do evil can find and apply the patches
without undue effort, and it could easily be that those applying the patches would
then make it even easier to abuse the new channels due to laziness or poor coding
choices.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 04/18/2017 09:33 AM, Steve deRosier wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 7:50 AM, Simon Wunderlich <sw@simonwunderlich.de <mailto:sw@simonwunderlich.de>> wrote:
>
>     Hi,
>
>     On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
>     > Simon Wunderlich <sw@simonwunderlich.de <mailto:sw@simonwunderlich.de>> wrote:
>     > > From: Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
>     > >
>     > > Many chips support channels in licensed bands. Add support for those,
>     > > along with a corresponding kernel config option to disable them by
>
> ...
>
>     > I am not sure that we should support unlicensed bands in Linux and hence
>     > hesitant to apply these. My view is that due to regulatory restrictions we
>     > should not make it too easy to use unlicensed bands. But I'm open for
>     > discussion, this is a challenging area and my knowledge here is limited.
>
> ...
>
>
>     In my personal view, we have quite a few obstacles which I consider "enough",
>     but would be interesting to hear others opinions ...
>
>
> I'll throw in my 2-cents. This patch is treading on very dangerous ground. I can't speak to other regulatory environments, but at least the FCC is cracking down
> on even the possibility that anyone can operate a WiFi device outside the regulatory bounds.

These patches make it slightly easier to use the licensed bands, but no one
can accidentally use them due to the regdb and other constaints in these
patches.

So, I don't think these patches offer any fundamental new vulnerability
that should concern the FCC.

After all, someone who really wants to do evil can find and apply the patches
without undue effort, and it could easily be that those applying the patches would
then make it even easier to abuse the new channels due to laziness or poor coding
choices.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

Hi,

On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> [...]
> >     In my personal view, we have quite a few obstacles which I consider
> >     "enough", but would be interesting to hear others opinions ...
> > 
> > I'll throw in my 2-cents. This patch is treading on very dangerous ground.
> > I can't speak to other regulatory environments, but at least the FCC is
> > cracking down on even the possibility that anyone can operate a WiFi
> > device outside the regulatory bounds.
> These patches make it slightly easier to use the licensed bands, but no one
> can accidentally use them due to the regdb and other constaints in these
> patches.
> 
> So, I don't think these patches offer any fundamental new vulnerability
> that should concern the FCC.
> 
> After all, someone who really wants to do evil can find and apply the
> patches without undue effort, and it could easily be that those applying
> the patches would then make it even easier to abuse the new channels due to
> laziness or poor coding choices.

I'm with Ben on this one. I also have followed the FCC actions in the past few 
years, and I've also been involved into that [1,2,3]. There are mailing lists 
on the topic if you want to get involved. I agree that the topic is important, 
but I would prefer to not have this patch serving as battleground. :)

The patches proposed here, as Ben says, at least put proper warnings and 
obstacles which users have to knowingly overcome (or read). It's probably 
safer than keeping the driver as is and having people apply random patches 
from the internet which they don't understand or hack the code themselves. 
Frankly, it's not that hard to enable those channels.

As we have seen by the number of questions and people trying to bring this 
patch in (Ben and Julian), there is quite some interest for supporting those 
bands. I've also got a few requests from companies to have it supported 
(Fraunhofer is one of those).

Cheers,
      Simon


[1] https://www.reddit.com/r/wireless/comments/3irr5b/
openwrt_vs_fcc_forced_firmware_lockdown/
[2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
[3] https://libreplanet.org/wiki/Save_WiFi

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

[-- Attachment #1.1: Type: text/plain, Size: 2230 bytes --]

Hi,

On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> [...]
> >     In my personal view, we have quite a few obstacles which I consider
> >     "enough", but would be interesting to hear others opinions ...
> > 
> > I'll throw in my 2-cents. This patch is treading on very dangerous ground.
> > I can't speak to other regulatory environments, but at least the FCC is
> > cracking down on even the possibility that anyone can operate a WiFi
> > device outside the regulatory bounds.
> These patches make it slightly easier to use the licensed bands, but no one
> can accidentally use them due to the regdb and other constaints in these
> patches.
> 
> So, I don't think these patches offer any fundamental new vulnerability
> that should concern the FCC.
> 
> After all, someone who really wants to do evil can find and apply the
> patches without undue effort, and it could easily be that those applying
> the patches would then make it even easier to abuse the new channels due to
> laziness or poor coding choices.

I'm with Ben on this one. I also have followed the FCC actions in the past few 
years, and I've also been involved into that [1,2,3]. There are mailing lists 
on the topic if you want to get involved. I agree that the topic is important, 
but I would prefer to not have this patch serving as battleground. :)

The patches proposed here, as Ben says, at least put proper warnings and 
obstacles which users have to knowingly overcome (or read). It's probably 
safer than keeping the driver as is and having people apply random patches 
from the internet which they don't understand or hack the code themselves. 
Frankly, it's not that hard to enable those channels.

As we have seen by the number of questions and people trying to bring this 
patch in (Ben and Julian), there is quite some interest for supporting those 
bands. I've also got a few requests from companies to have it supported 
(Fraunhofer is one of those).

Cheers,
      Simon


[1] https://www.reddit.com/r/wireless/comments/3irr5b/
openwrt_vs_fcc_forced_firmware_lockdown/
[2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
[3] https://libreplanet.org/wiki/Save_WiFi

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Mathias Kretschmer]

Hi all,

as one of the parties who triggered this patch to be included into the 
main line kernel, we do support Simon's or Ben's point of view.

Safeguards against accidental misuse are in place. Various patches are 
(have been) already in the open, so if someone wants to be evil, it 
can't be prevented.

Also, these patches do not make up new channels out of the blue, they 
merely enable channels which are allowed in certain countries under 
specific regulations. To me it seems to be the task of the distribution 
manager (or manufacturer) to ensure that only hardware/kernel features 
are made available that are legal in the given jurisdiction.

The default behavior is to disable those extra channels. If you are 
building, i.e. First Responder solutions, you need to ensure that those 
guys use the systems incl. the frequency spectrum accordingly.

To be pragmatic and to avoid out-of-tree code maintenance, my vote would 
be for integration into mainline.

Best regards,

Mathias




Hence, for

On 21-Apr-17 13:29, Simon Wunderlich wrote:
> Hi,
> 
> On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
>> [...]
>>>      In my personal view, we have quite a few obstacles which I consider
>>>      "enough", but would be interesting to hear others opinions ...
>>>
>>> I'll throw in my 2-cents. This patch is treading on very dangerous ground.
>>> I can't speak to other regulatory environments, but at least the FCC is
>>> cracking down on even the possibility that anyone can operate a WiFi
>>> device outside the regulatory bounds.
>> These patches make it slightly easier to use the licensed bands, but no one
>> can accidentally use them due to the regdb and other constaints in these
>> patches.
>>
>> So, I don't think these patches offer any fundamental new vulnerability
>> that should concern the FCC.
>>
>> After all, someone who really wants to do evil can find and apply the
>> patches without undue effort, and it could easily be that those applying
>> the patches would then make it even easier to abuse the new channels due to
>> laziness or poor coding choices.
> 
> I'm with Ben on this one. I also have followed the FCC actions in the past few
> years, and I've also been involved into that [1,2,3]. There are mailing lists
> on the topic if you want to get involved. I agree that the topic is important,
> but I would prefer to not have this patch serving as battleground. :)
> 
> The patches proposed here, as Ben says, at least put proper warnings and
> obstacles which users have to knowingly overcome (or read). It's probably
> safer than keeping the driver as is and having people apply random patches
> from the internet which they don't understand or hack the code themselves.
> Frankly, it's not that hard to enable those channels.
> 
> As we have seen by the number of questions and people trying to bring this
> patch in (Ben and Julian), there is quite some interest for supporting those
> bands. I've also got a few requests from companies to have it supported
> (Fraunhofer is one of those).
> 
> Cheers,
>        Simon
> 
> 
> [1] https://www.reddit.com/r/wireless/comments/3irr5b/
> openwrt_vs_fcc_forced_firmware_lockdown/
> [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> [3] https://libreplanet.org/wiki/Save_WiFi
> 

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Mathias Kretschmer]

Hi all,

as one of the parties who triggered this patch to be included into the 
main line kernel, we do support Simon's or Ben's point of view.

Safeguards against accidental misuse are in place. Various patches are 
(have been) already in the open, so if someone wants to be evil, it 
can't be prevented.

Also, these patches do not make up new channels out of the blue, they 
merely enable channels which are allowed in certain countries under 
specific regulations. To me it seems to be the task of the distribution 
manager (or manufacturer) to ensure that only hardware/kernel features 
are made available that are legal in the given jurisdiction.

The default behavior is to disable those extra channels. If you are 
building, i.e. First Responder solutions, you need to ensure that those 
guys use the systems incl. the frequency spectrum accordingly.

To be pragmatic and to avoid out-of-tree code maintenance, my vote would 
be for integration into mainline.

Best regards,

Mathias




Hence, for

On 21-Apr-17 13:29, Simon Wunderlich wrote:
> Hi,
> 
> On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
>> [...]
>>>      In my personal view, we have quite a few obstacles which I consider
>>>      "enough", but would be interesting to hear others opinions ...
>>>
>>> I'll throw in my 2-cents. This patch is treading on very dangerous ground.
>>> I can't speak to other regulatory environments, but at least the FCC is
>>> cracking down on even the possibility that anyone can operate a WiFi
>>> device outside the regulatory bounds.
>> These patches make it slightly easier to use the licensed bands, but no one
>> can accidentally use them due to the regdb and other constaints in these
>> patches.
>>
>> So, I don't think these patches offer any fundamental new vulnerability
>> that should concern the FCC.
>>
>> After all, someone who really wants to do evil can find and apply the
>> patches without undue effort, and it could easily be that those applying
>> the patches would then make it even easier to abuse the new channels due to
>> laziness or poor coding choices.
> 
> I'm with Ben on this one. I also have followed the FCC actions in the past few
> years, and I've also been involved into that [1,2,3]. There are mailing lists
> on the topic if you want to get involved. I agree that the topic is important,
> but I would prefer to not have this patch serving as battleground. :)
> 
> The patches proposed here, as Ben says, at least put proper warnings and
> obstacles which users have to knowingly overcome (or read). It's probably
> safer than keeping the driver as is and having people apply random patches
> from the internet which they don't understand or hack the code themselves.
> Frankly, it's not that hard to enable those channels.
> 
> As we have seen by the number of questions and people trying to bring this
> patch in (Ben and Julian), there is quite some interest for supporting those
> bands. I've also got a few requests from companies to have it supported
> (Fraunhofer is one of those).
> 
> Cheers,
>        Simon
> 
> 
> [1] https://www.reddit.com/r/wireless/comments/3irr5b/
> openwrt_vs_fcc_forced_firmware_lockdown/
> [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> [3] https://libreplanet.org/wiki/Save_WiFi
> 


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]

Hey Kalle,

it seems like there was some discussion here and I wouldn't expect too many 
more opinions ... do you think we can have a decision based on what has been 
discussed here?

I'd be happy to rebase the remaining patches if that is necessary.

Thank you!
     Simon

On Friday, April 21, 2017 2:40:51 PM CEST Mathias Kretschmer wrote:
> Hi all,
> 
> as one of the parties who triggered this patch to be included into the
> main line kernel, we do support Simon's or Ben's point of view.
> 
> Safeguards against accidental misuse are in place. Various patches are
> (have been) already in the open, so if someone wants to be evil, it
> can't be prevented.
> 
> Also, these patches do not make up new channels out of the blue, they
> merely enable channels which are allowed in certain countries under
> specific regulations. To me it seems to be the task of the distribution
> manager (or manufacturer) to ensure that only hardware/kernel features
> are made available that are legal in the given jurisdiction.
> 
> The default behavior is to disable those extra channels. If you are
> building, i.e. First Responder solutions, you need to ensure that those
> guys use the systems incl. the frequency spectrum accordingly.
> 
> To be pragmatic and to avoid out-of-tree code maintenance, my vote would
> be for integration into mainline.
> 
> Best regards,
> 
> Mathias
> 
> 
> 
> 
> Hence, for
> 
> On 21-Apr-17 13:29, Simon Wunderlich wrote:
> > Hi,
> > 
> > On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> >> [...]
> >> 
> >>>      In my personal view, we have quite a few obstacles which I consider
> >>>      "enough", but would be interesting to hear others opinions ...
> >>> 
> >>> I'll throw in my 2-cents. This patch is treading on very dangerous
> >>> ground.
> >>> I can't speak to other regulatory environments, but at least the FCC is
> >>> cracking down on even the possibility that anyone can operate a WiFi
> >>> device outside the regulatory bounds.
> >> 
> >> These patches make it slightly easier to use the licensed bands, but no
> >> one
> >> can accidentally use them due to the regdb and other constaints in these
> >> patches.
> >> 
> >> So, I don't think these patches offer any fundamental new vulnerability
> >> that should concern the FCC.
> >> 
> >> After all, someone who really wants to do evil can find and apply the
> >> patches without undue effort, and it could easily be that those applying
> >> the patches would then make it even easier to abuse the new channels due
> >> to
> >> laziness or poor coding choices.
> > 
> > I'm with Ben on this one. I also have followed the FCC actions in the past
> > few years, and I've also been involved into that [1,2,3]. There are
> > mailing lists on the topic if you want to get involved. I agree that the
> > topic is important, but I would prefer to not have this patch serving as
> > battleground. :)
> > 
> > The patches proposed here, as Ben says, at least put proper warnings and
> > obstacles which users have to knowingly overcome (or read). It's probably
> > safer than keeping the driver as is and having people apply random patches
> > from the internet which they don't understand or hack the code themselves.
> > Frankly, it's not that hard to enable those channels.
> > 
> > As we have seen by the number of questions and people trying to bring this
> > patch in (Ben and Julian), there is quite some interest for supporting
> > those bands. I've also got a few requests from companies to have it
> > supported (Fraunhofer is one of those).
> > 
> > Cheers,
> > 
> >        Simon
> > 
> > [1] https://www.reddit.com/r/wireless/comments/3irr5b/
> > openwrt_vs_fcc_forced_firmware_lockdown/
> > [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> > [3] https://libreplanet.org/wiki/Save_WiFi
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

[-- Attachment #1.1: Type: text/plain, Size: 3980 bytes --]

Hey Kalle,

it seems like there was some discussion here and I wouldn't expect too many 
more opinions ... do you think we can have a decision based on what has been 
discussed here?

I'd be happy to rebase the remaining patches if that is necessary.

Thank you!
     Simon

On Friday, April 21, 2017 2:40:51 PM CEST Mathias Kretschmer wrote:
> Hi all,
> 
> as one of the parties who triggered this patch to be included into the
> main line kernel, we do support Simon's or Ben's point of view.
> 
> Safeguards against accidental misuse are in place. Various patches are
> (have been) already in the open, so if someone wants to be evil, it
> can't be prevented.
> 
> Also, these patches do not make up new channels out of the blue, they
> merely enable channels which are allowed in certain countries under
> specific regulations. To me it seems to be the task of the distribution
> manager (or manufacturer) to ensure that only hardware/kernel features
> are made available that are legal in the given jurisdiction.
> 
> The default behavior is to disable those extra channels. If you are
> building, i.e. First Responder solutions, you need to ensure that those
> guys use the systems incl. the frequency spectrum accordingly.
> 
> To be pragmatic and to avoid out-of-tree code maintenance, my vote would
> be for integration into mainline.
> 
> Best regards,
> 
> Mathias
> 
> 
> 
> 
> Hence, for
> 
> On 21-Apr-17 13:29, Simon Wunderlich wrote:
> > Hi,
> > 
> > On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> >> [...]
> >> 
> >>>      In my personal view, we have quite a few obstacles which I consider
> >>>      "enough", but would be interesting to hear others opinions ...
> >>> 
> >>> I'll throw in my 2-cents. This patch is treading on very dangerous
> >>> ground.
> >>> I can't speak to other regulatory environments, but at least the FCC is
> >>> cracking down on even the possibility that anyone can operate a WiFi
> >>> device outside the regulatory bounds.
> >> 
> >> These patches make it slightly easier to use the licensed bands, but no
> >> one
> >> can accidentally use them due to the regdb and other constaints in these
> >> patches.
> >> 
> >> So, I don't think these patches offer any fundamental new vulnerability
> >> that should concern the FCC.
> >> 
> >> After all, someone who really wants to do evil can find and apply the
> >> patches without undue effort, and it could easily be that those applying
> >> the patches would then make it even easier to abuse the new channels due
> >> to
> >> laziness or poor coding choices.
> > 
> > I'm with Ben on this one. I also have followed the FCC actions in the past
> > few years, and I've also been involved into that [1,2,3]. There are
> > mailing lists on the topic if you want to get involved. I agree that the
> > topic is important, but I would prefer to not have this patch serving as
> > battleground. :)
> > 
> > The patches proposed here, as Ben says, at least put proper warnings and
> > obstacles which users have to knowingly overcome (or read). It's probably
> > safer than keeping the driver as is and having people apply random patches
> > from the internet which they don't understand or hack the code themselves.
> > Frankly, it's not that hard to enable those channels.
> > 
> > As we have seen by the number of questions and people trying to bring this
> > patch in (Ben and Julian), there is quite some interest for supporting
> > those bands. I've also got a few requests from companies to have it
> > supported (Fraunhofer is one of those).
> > 
> > Cheers,
> > 
> >        Simon
> > 
> > [1] https://www.reddit.com/r/wireless/comments/3irr5b/
> > openwrt_vs_fcc_forced_firmware_lockdown/
> > [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> > [3] https://libreplanet.org/wiki/Save_WiFi
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Adrian Chadd]

On 9 May 2017 at 05:57, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> Hey Kalle,
>
> it seems like there was some discussion here and I wouldn't expect too many
> more opinions ... do you think we can have a decision based on what has been
> discussed here?

(Note: FreeBSD has had in-tree support for 4.9GHz and 900MHz bands
since forever. I'm actually thinking of extending it to include 5.9
and other UHF bands to cover licenced hardware people are making but
then leaving the support disabled unless you compile in very specific
licenced bits. No, it doesn't work out of the box unless your NIC
actually supports it in the calibration section.)

(Note note: some of those channels have non-megahertz boundaries,
which means ... yeah, hello inter-operability boundaries. Hilarious.)



-adrian

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Adrian Chadd]

On 9 May 2017 at 05:57, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> Hey Kalle,
>
> it seems like there was some discussion here and I wouldn't expect too many
> more opinions ... do you think we can have a decision based on what has been
> discussed here?

(Note: FreeBSD has had in-tree support for 4.9GHz and 900MHz bands
since forever. I'm actually thinking of extending it to include 5.9
and other UHF bands to cover licenced hardware people are making but
then leaving the support disabled unless you compile in very specific
licenced bits. No, it doesn't work out of the box unless your NIC
actually supports it in the calibration section.)

(Note note: some of those channels have non-megahertz boundaries,
which means ... yeah, hello inter-operability boundaries. Hilarious.)



-adrian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 05/10/2017 03:30 AM, Tom Psyborg wrote:
>
>
> On 9 May 2017 at 19:50, Adrian Chadd <adrian@freebsd.org <mailto:adrian@freebsd.org>> wrote:
>
>
>     (Note note: some of those channels have non-megahertz boundaries,
>     which means ... yeah, hello inter-operability boundaries. Hilarious.)
>
>
>
>     -adrian
>
>
>
> From what I can tell, it seems like as long as your both points are configured with identical settings, you can use any channel/frequency/bandwidth combination
> that hardware supports. Possibly even 802.11ac at 2.4 GHz if we got more than 100MHz of bandwidth from 2.4 to 2.5 GHz. The solution i've made myself doesn't
> include all available channels but can serve as an example: https://forum.openwrt.org/viewtopic.php?pid=353870#p353870 primary/sec HT channel option should also
> be further extended.
>
> Cheers, Tom

I've successfully used 802.11ac VHT-40 on 2.4Ghz band with ath10k...it just requires a few small changes
in the mac80211 stack to allow it to be configured....just FYI.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 05/10/2017 03:30 AM, Tom Psyborg wrote:
>
>
> On 9 May 2017 at 19:50, Adrian Chadd <adrian@freebsd.org <mailto:adrian@freebsd.org>> wrote:
>
>
>     (Note note: some of those channels have non-megahertz boundaries,
>     which means ... yeah, hello inter-operability boundaries. Hilarious.)
>
>
>
>     -adrian
>
>
>
> From what I can tell, it seems like as long as your both points are configured with identical settings, you can use any channel/frequency/bandwidth combination
> that hardware supports. Possibly even 802.11ac at 2.4 GHz if we got more than 100MHz of bandwidth from 2.4 to 2.5 GHz. The solution i've made myself doesn't
> include all available channels but can serve as an example: https://forum.openwrt.org/viewtopic.php?pid=353870#p353870 primary/sec HT channel option should also
> be further extended.
>
> Cheers, Tom

I've successfully used 802.11ac VHT-40 on 2.4Ghz band with ath10k...it just requires a few small changes
in the mac80211 stack to allow it to be configured....just FYI.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Kalle Valo]

Simon Wunderlich <sw@simonwunderlich.de> writes:

> it seems like there was some discussion here and I wouldn't expect too many 
> more opinions ... do you think we can have a decision based on what has been 
> discussed here?

Well, there was an excellent reply from Steve and quite a few "in my
opinion this is safe" type of answers. [1] But bluntly said it does not
really matter what we (the engineers) think. What really matters here
are regulatory authorities' opinions and rulings. In that respect here
are few items I want to point out:

o I suspect that from someone's, who is not familiar with software
  engineering, point of view there is still quite a diffference from
  modifiying source code or just enabling few options from Kconfig with
  a custom regdb rule.

o I don't know about other countries, but in Finland applying for any
  type of license (even if just to a license to drive a moped) needs
  both time and money. So there is significant effort anyway needed to
  legally use this band. And how many users there really are is unclear.

o Also this is not about enabling or disabling channel 13, but about a
  public _safety_ band which makes me very uneasy.

So the way I see this is that the risks outweigh the benefits and that's
why I do not want to take these. Sorry.

[1] https://patchwork.kernel.org/patch/9641105/

-- 
Kalle Valo

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Kalle Valo]

Simon Wunderlich <sw@simonwunderlich.de> writes:

> it seems like there was some discussion here and I wouldn't expect too many 
> more opinions ... do you think we can have a decision based on what has been 
> discussed here?

Well, there was an excellent reply from Steve and quite a few "in my
opinion this is safe" type of answers. [1] But bluntly said it does not
really matter what we (the engineers) think. What really matters here
are regulatory authorities' opinions and rulings. In that respect here
are few items I want to point out:

o I suspect that from someone's, who is not familiar with software
  engineering, point of view there is still quite a diffference from
  modifiying source code or just enabling few options from Kconfig with
  a custom regdb rule.

o I don't know about other countries, but in Finland applying for any
  type of license (even if just to a license to drive a moped) needs
  both time and money. So there is significant effort anyway needed to
  legally use this band. And how many users there really are is unclear.

o Also this is not about enabling or disabling channel 13, but about a
  public _safety_ band which makes me very uneasy.

So the way I see this is that the risks outweigh the benefits and that's
why I do not want to take these. Sorry.

[1] https://patchwork.kernel.org/patch/9641105/

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 05/11/2017 04:38 AM, Kalle Valo wrote:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
>
>> it seems like there was some discussion here and I wouldn't expect too many
>> more opinions ... do you think we can have a decision based on what has been
>> discussed here?
>
> Well, there was an excellent reply from Steve and quite a few "in my
> opinion this is safe" type of answers. [1] But bluntly said it does not
> really matter what we (the engineers) think. What really matters here
> are regulatory authorities' opinions and rulings. In that respect here
> are few items I want to point out:
>
> o I suspect that from someone's, who is not familiar with software
>   engineering, point of view there is still quite a diffference from
>   modifiying source code or just enabling few options from Kconfig with
>   a custom regdb rule.

If someone with real authority ever complains, then the code could be
backed out again.  Your opinion seems not much more informed than the
rest of us discussing this.

>
> o I don't know about other countries, but in Finland applying for any
>   type of license (even if just to a license to drive a moped) needs
>   both time and money. So there is significant effort anyway needed to
>   legally use this band. And how many users there really are is unclear.

This is almost certainly not going to be used by regular end-users.  It is going to be
used by public safety organizations who are buying equipment from companies
using open-wrt, LEDE, or similar, or possibly small teams at public safety
organizations doing the work themselves.  Rather than having each of these vendors
hack their own crap into their kernels or forcing the the organizations to use Cisco gear,
we could work on it together.

Anyway, if upstream is blocked, then maybe we could work on getting this into LEDE?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 05/11/2017 04:38 AM, Kalle Valo wrote:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
>
>> it seems like there was some discussion here and I wouldn't expect too many
>> more opinions ... do you think we can have a decision based on what has been
>> discussed here?
>
> Well, there was an excellent reply from Steve and quite a few "in my
> opinion this is safe" type of answers. [1] But bluntly said it does not
> really matter what we (the engineers) think. What really matters here
> are regulatory authorities' opinions and rulings. In that respect here
> are few items I want to point out:
>
> o I suspect that from someone's, who is not familiar with software
>   engineering, point of view there is still quite a diffference from
>   modifiying source code or just enabling few options from Kconfig with
>   a custom regdb rule.

If someone with real authority ever complains, then the code could be
backed out again.  Your opinion seems not much more informed than the
rest of us discussing this.

>
> o I don't know about other countries, but in Finland applying for any
>   type of license (even if just to a license to drive a moped) needs
>   both time and money. So there is significant effort anyway needed to
>   legally use this band. And how many users there really are is unclear.

This is almost certainly not going to be used by regular end-users.  It is going to be
used by public safety organizations who are buying equipment from companies
using open-wrt, LEDE, or similar, or possibly small teams at public safety
organizations doing the work themselves.  Rather than having each of these vendors
hack their own crap into their kernels or forcing the the organizations to use Cisco gear,
we could work on it together.

Anyway, if upstream is blocked, then maybe we could work on getting this into LEDE?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Steve deRosier]

Hi Ben,

On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>
>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>>
>>> it seems like there was some discussion here and I wouldn't expect too
>>> many
>>> more opinions ... do you think we can have a decision based on what has
>>> been
>>> discussed here?
>>
>>
>> Well, there was an excellent reply from Steve and quite a few "in my
>> opinion this is safe" type of answers. [1] But bluntly said it does not
>> really matter what we (the engineers) think. What really matters here
>> are regulatory authorities' opinions and rulings. In that respect here
>> are few items I want to point out:
>>
>> o I suspect that from someone's, who is not familiar with software
>>   engineering, point of view there is still quite a diffference from
>>   modifiying source code or just enabling few options from Kconfig with
>>   a custom regdb rule.
>
>
> If someone with real authority ever complains, then the code could be
> backed out again.  Your opinion seems not much more informed than the
> rest of us discussing this.
>

With all due respect, _I_ am quite well informed about this issue.
>From my conversations with him, I'd also judge Kalle to be quite
informed likewise.

"Someone with real authority" has already complained. That's the
entire point here. For the past two+ years it's been difficult to get
modular approvals through the FCC and their TCBs. The standard they
are applying is both pointless and technically misinformed, but
they've got the authority and they're using it. I can't speak for any
other manufacturers other than what I specifically have experience
with, but I expect the rest are having similar conversations with the
TCBs. From my work with them, I know that the chip manufacturers like
QCA, Marvell and Cypress/Broadcom are also having similar issues.
However, the chip manufacturers, and end-user equipment manufacturers
are less vulnerable here than the module manufacturers.


>>
>> o I don't know about other countries, but in Finland applying for any
>>   type of license (even if just to a license to drive a moped) needs
>>   both time and money. So there is significant effort anyway needed to
>>   legally use this band. And how many users there really are is unclear.
>
>
> This is almost certainly not going to be used by regular end-users.  It is
> going to be
> used by public safety organizations who are buying equipment from companies
> using open-wrt, LEDE, or similar, or possibly small teams at public safety
> organizations doing the work themselves.  Rather than having each of these
> vendors

I agree 100% that this won't be used by "regular end-users", if you
define those users as the 99% of the population who will go to Best
Buy and buy a router, plug it into their network and use it to get
their iOS updates and download movies from Netflix. These aren't the
users that the FCC is worried about.  They're concerned about the user
who buys an OpenWRT compatible router, installs OpenWRT on it, builds
a custom kernel. And that person happens to live in an area with
congested WiFi bands, the person notices an option to use these other
non-congested bands, decides that ignoring the warning would be
harmless and the FCC won't ever know anyway.

And then there's a fire or other event in the area, and the emergency
workers can't communicate. At best case, the FCC investigates and
slaps a $25,000 fine on the operator. At worst case, someone dies.

I don't feel it's responsible as an engineer to hide behind "well, we
warned them that they shouldn't do that" while ignoring my culpability
in the matter. Setting the stage for others to fail due to their
ignorance is not ethical.

Anyone building a custom kernel is able to enable a config option. You
can say that, "sure they can pull the patch from here and enable it
anyway" or "they can figure it out and do it themselves, it's easy",
but I do think there's a significant difference between being able to
build a custom kernel with a configuration enabled vs being able to
find and apply a random patch to a kernel and get it building and
working. That's a different level of expertise. And going through that
effort gives a person some time to reflect and think about if it
should be done in the first place.

Adding this code to mainline makes it a feature of Linux and this
driver. There's no way around that argument. Saying that "this is
almost certainly not going to be used by regular end-users" is both
fairly true as well as disingenuous. You're still making it an
accepted feature.


> hack their own crap into their kernels or forcing the the organizations to
> use Cisco gear,
> we could work on it together.
>

I absolutely concur with the idea of "we could work on it together."
Working together means coming up with a holistic plan that will work
and satisfy the regulatory agencies (and I'm not just talking FCC,
though they're right now one of the worst offenders IMHO). Just
putting a patch to use licenced public-safety bands into a single
random 802.11 chip driver to satisfy your particular
project/product/itch is not the same as working together. In
particular because this is _exactly_ the type of stuff that the FCC is
actually concerned about and fighting against with their misinformed
lock-down attitudes.

What really needs to happen to solve these sort of issues is a
whole-system approach where we work with the agencies and figure out a
way that works for everyone. The lawmakers and the regulatory agencies
as a group entity don't understand software, electronics, technology,
nor Open Source. The whole idea of a bunch of us "hackers" able to do
anything we want with just a few lines of code scares the hell out of
them. We need to engage with them. Educate them. Work with the
specific people inside their organizations that _do_ understand the
technology. Let them understand we're not the enemy and then work with
them to achieve both their goals and ours.

I tried to get the ball rolling on this at the Wireless Summit at the
last LPC, but no one bit. Probably some due to the lack of clarity
around the issue as well as my lack of eloquence, but no matter why,
it didn't go anywhere. I'm happy to try again if people are
interested.

This isn't just about letting it operate out of spec, nor a technical
argument. I don't have any issue with making it easier to enable a
feature of the chipset. That's all good. But "making it easier" in
this case equates to making it harder for the entire community who
depends on this stuff to get their work done and their products
certified. That's a net negative.

> Anyway, if upstream is blocked, then maybe we could work on getting this
> into LEDE?
>

Honestly, I don't see how this solves any problems. You're just moving
the chair. A chair that someone will stand on and fall off and get
hurt. LEDE, OpenWRT or even Buildroot is essentially just a big patch
and build system. For a closed-ecosystem manufacturer, which by
definition a public-safety band licensed equipment manufacturer must
be, can just as easily maintain their own internal fork of the kernel
with these patches sitting there.

That's not something I'd normally advocate, but it does seem
appropriate in this specific application.

Thanks,
- Steve

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Steve deRosier]

Hi Ben,

On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>
>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>>
>>> it seems like there was some discussion here and I wouldn't expect too
>>> many
>>> more opinions ... do you think we can have a decision based on what has
>>> been
>>> discussed here?
>>
>>
>> Well, there was an excellent reply from Steve and quite a few "in my
>> opinion this is safe" type of answers. [1] But bluntly said it does not
>> really matter what we (the engineers) think. What really matters here
>> are regulatory authorities' opinions and rulings. In that respect here
>> are few items I want to point out:
>>
>> o I suspect that from someone's, who is not familiar with software
>>   engineering, point of view there is still quite a diffference from
>>   modifiying source code or just enabling few options from Kconfig with
>>   a custom regdb rule.
>
>
> If someone with real authority ever complains, then the code could be
> backed out again.  Your opinion seems not much more informed than the
> rest of us discussing this.
>

With all due respect, _I_ am quite well informed about this issue.
From my conversations with him, I'd also judge Kalle to be quite
informed likewise.

"Someone with real authority" has already complained. That's the
entire point here. For the past two+ years it's been difficult to get
modular approvals through the FCC and their TCBs. The standard they
are applying is both pointless and technically misinformed, but
they've got the authority and they're using it. I can't speak for any
other manufacturers other than what I specifically have experience
with, but I expect the rest are having similar conversations with the
TCBs. From my work with them, I know that the chip manufacturers like
QCA, Marvell and Cypress/Broadcom are also having similar issues.
However, the chip manufacturers, and end-user equipment manufacturers
are less vulnerable here than the module manufacturers.


>>
>> o I don't know about other countries, but in Finland applying for any
>>   type of license (even if just to a license to drive a moped) needs
>>   both time and money. So there is significant effort anyway needed to
>>   legally use this band. And how many users there really are is unclear.
>
>
> This is almost certainly not going to be used by regular end-users.  It is
> going to be
> used by public safety organizations who are buying equipment from companies
> using open-wrt, LEDE, or similar, or possibly small teams at public safety
> organizations doing the work themselves.  Rather than having each of these
> vendors

I agree 100% that this won't be used by "regular end-users", if you
define those users as the 99% of the population who will go to Best
Buy and buy a router, plug it into their network and use it to get
their iOS updates and download movies from Netflix. These aren't the
users that the FCC is worried about.  They're concerned about the user
who buys an OpenWRT compatible router, installs OpenWRT on it, builds
a custom kernel. And that person happens to live in an area with
congested WiFi bands, the person notices an option to use these other
non-congested bands, decides that ignoring the warning would be
harmless and the FCC won't ever know anyway.

And then there's a fire or other event in the area, and the emergency
workers can't communicate. At best case, the FCC investigates and
slaps a $25,000 fine on the operator. At worst case, someone dies.

I don't feel it's responsible as an engineer to hide behind "well, we
warned them that they shouldn't do that" while ignoring my culpability
in the matter. Setting the stage for others to fail due to their
ignorance is not ethical.

Anyone building a custom kernel is able to enable a config option. You
can say that, "sure they can pull the patch from here and enable it
anyway" or "they can figure it out and do it themselves, it's easy",
but I do think there's a significant difference between being able to
build a custom kernel with a configuration enabled vs being able to
find and apply a random patch to a kernel and get it building and
working. That's a different level of expertise. And going through that
effort gives a person some time to reflect and think about if it
should be done in the first place.

Adding this code to mainline makes it a feature of Linux and this
driver. There's no way around that argument. Saying that "this is
almost certainly not going to be used by regular end-users" is both
fairly true as well as disingenuous. You're still making it an
accepted feature.


> hack their own crap into their kernels or forcing the the organizations to
> use Cisco gear,
> we could work on it together.
>

I absolutely concur with the idea of "we could work on it together."
Working together means coming up with a holistic plan that will work
and satisfy the regulatory agencies (and I'm not just talking FCC,
though they're right now one of the worst offenders IMHO). Just
putting a patch to use licenced public-safety bands into a single
random 802.11 chip driver to satisfy your particular
project/product/itch is not the same as working together. In
particular because this is _exactly_ the type of stuff that the FCC is
actually concerned about and fighting against with their misinformed
lock-down attitudes.

What really needs to happen to solve these sort of issues is a
whole-system approach where we work with the agencies and figure out a
way that works for everyone. The lawmakers and the regulatory agencies
as a group entity don't understand software, electronics, technology,
nor Open Source. The whole idea of a bunch of us "hackers" able to do
anything we want with just a few lines of code scares the hell out of
them. We need to engage with them. Educate them. Work with the
specific people inside their organizations that _do_ understand the
technology. Let them understand we're not the enemy and then work with
them to achieve both their goals and ours.

I tried to get the ball rolling on this at the Wireless Summit at the
last LPC, but no one bit. Probably some due to the lack of clarity
around the issue as well as my lack of eloquence, but no matter why,
it didn't go anywhere. I'm happy to try again if people are
interested.

This isn't just about letting it operate out of spec, nor a technical
argument. I don't have any issue with making it easier to enable a
feature of the chipset. That's all good. But "making it easier" in
this case equates to making it harder for the entire community who
depends on this stuff to get their work done and their products
certified. That's a net negative.

> Anyway, if upstream is blocked, then maybe we could work on getting this
> into LEDE?
>

Honestly, I don't see how this solves any problems. You're just moving
the chair. A chair that someone will stand on and fall off and get
hurt. LEDE, OpenWRT or even Buildroot is essentially just a big patch
and build system. For a closed-ecosystem manufacturer, which by
definition a public-safety band licensed equipment manufacturer must
be, can just as easily maintain their own internal fork of the kernel
with these patches sitting there.

That's not something I'd normally advocate, but it does seem
appropriate in this specific application.

Thanks,
- Steve

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 05/12/2017 12:21 PM, Steve deRosier wrote:
> Hi Ben,
>
> On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>>
>>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>>>
>>>> it seems like there was some discussion here and I wouldn't expect too
>>>> many
>>>> more opinions ... do you think we can have a decision based on what has
>>>> been
>>>> discussed here?
>>>
>>>
>>> Well, there was an excellent reply from Steve and quite a few "in my
>>> opinion this is safe" type of answers. [1] But bluntly said it does not
>>> really matter what we (the engineers) think. What really matters here
>>> are regulatory authorities' opinions and rulings. In that respect here
>>> are few items I want to point out:
>>>
>>> o I suspect that from someone's, who is not familiar with software
>>>   engineering, point of view there is still quite a diffference from
>>>   modifiying source code or just enabling few options from Kconfig with
>>>   a custom regdb rule.
>>
>>
>> If someone with real authority ever complains, then the code could be
>> backed out again.  Your opinion seems not much more informed than the
>> rest of us discussing this.
>>
>
> With all due respect, _I_ am quite well informed about this issue.
> From my conversations with him, I'd also judge Kalle to be quite
> informed likewise.

>> Anyway, if upstream is blocked, then maybe we could work on getting this
>> into LEDE?
>>
>
> Honestly, I don't see how this solves any problems. You're just moving
> the chair. A chair that someone will stand on and fall off and get
> hurt. LEDE, OpenWRT or even Buildroot is essentially just a big patch
> and build system. For a closed-ecosystem manufacturer, which by
> definition a public-safety band licensed equipment manufacturer must
> be, can just as easily maintain their own internal fork of the kernel
> with these patches sitting there.
>
> That's not something I'd normally advocate, but it does seem
> appropriate in this specific application.

Maintaining outside patches means work for everyone..but if there
is a single set of outside patches, then at least it is easier.
That is what LEDE might be able to offer.

As for keeping lame users from causing trouble, maybe we can merge
much of the code that often conflicts with upstream code but leave out a few key patches
to actually enable the feature.  Then no one can just re-build
with a different kernel option (after hacking their regdb) and
get it to work.

All that said, I doubt this will matter at all to FCC because
if LEDE can boot on a device, it can already be put out of spec
without much trouble.  Making it take 2 days of effort vs 1 hour
surely doesn't make a difference?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Ben Greear]

On 05/12/2017 12:21 PM, Steve deRosier wrote:
> Hi Ben,
>
> On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>>
>>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>>>
>>>> it seems like there was some discussion here and I wouldn't expect too
>>>> many
>>>> more opinions ... do you think we can have a decision based on what has
>>>> been
>>>> discussed here?
>>>
>>>
>>> Well, there was an excellent reply from Steve and quite a few "in my
>>> opinion this is safe" type of answers. [1] But bluntly said it does not
>>> really matter what we (the engineers) think. What really matters here
>>> are regulatory authorities' opinions and rulings. In that respect here
>>> are few items I want to point out:
>>>
>>> o I suspect that from someone's, who is not familiar with software
>>>   engineering, point of view there is still quite a diffference from
>>>   modifiying source code or just enabling few options from Kconfig with
>>>   a custom regdb rule.
>>
>>
>> If someone with real authority ever complains, then the code could be
>> backed out again.  Your opinion seems not much more informed than the
>> rest of us discussing this.
>>
>
> With all due respect, _I_ am quite well informed about this issue.
> From my conversations with him, I'd also judge Kalle to be quite
> informed likewise.

>> Anyway, if upstream is blocked, then maybe we could work on getting this
>> into LEDE?
>>
>
> Honestly, I don't see how this solves any problems. You're just moving
> the chair. A chair that someone will stand on and fall off and get
> hurt. LEDE, OpenWRT or even Buildroot is essentially just a big patch
> and build system. For a closed-ecosystem manufacturer, which by
> definition a public-safety band licensed equipment manufacturer must
> be, can just as easily maintain their own internal fork of the kernel
> with these patches sitting there.
>
> That's not something I'd normally advocate, but it does seem
> appropriate in this specific application.

Maintaining outside patches means work for everyone..but if there
is a single set of outside patches, then at least it is easier.
That is what LEDE might be able to offer.

As for keeping lame users from causing trouble, maybe we can merge
much of the code that often conflicts with upstream code but leave out a few key patches
to actually enable the feature.  Then no one can just re-build
with a different kernel option (after hacking their regdb) and
get it to work.

All that said, I doubt this will matter at all to FCC because
if LEDE can boot on a device, it can already be put out of spec
without much trouble.  Making it take 2 days of effort vs 1 hour
surely doesn't make a difference?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Arend Van Spriel]

On 12-5-2017 21:21, Steve deRosier wrote:
> Hi Ben,
> 
> On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>>

[snip]

>>> o I don't know about other countries, but in Finland applying for any
>>>   type of license (even if just to a license to drive a moped) needs
>>>   both time and money. So there is significant effort anyway needed to
>>>   legally use this band. And how many users there really are is unclear.
>>
>>
>> This is almost certainly not going to be used by regular end-users.  It is
>> going to be
>> used by public safety organizations who are buying equipment from companies
>> using open-wrt, LEDE, or similar, or possibly small teams at public safety
>> organizations doing the work themselves.  Rather than having each of these
>> vendors
> 
> I agree 100% that this won't be used by "regular end-users", if you
> define those users as the 99% of the population who will go to Best
> Buy and buy a router, plug it into their network and use it to get
> their iOS updates and download movies from Netflix. These aren't the
> users that the FCC is worried about.  They're concerned about the user
> who buys an OpenWRT compatible router, installs OpenWRT on it, builds
> a custom kernel. And that person happens to live in an area with
> congested WiFi bands, the person notices an option to use these other
> non-congested bands, decides that ignoring the warning would be
> harmless and the FCC won't ever know anyway.
> 
> And then there's a fire or other event in the area, and the emergency
> workers can't communicate. At best case, the FCC investigates and
> slaps a $25,000 fine on the operator. At worst case, someone dies.
> 
> I don't feel it's responsible as an engineer to hide behind "well, we
> warned them that they shouldn't do that" while ignoring my culpability
> in the matter. Setting the stage for others to fail due to their
> ignorance is not ethical.

Totally agree this is about being responsible.

> Anyone building a custom kernel is able to enable a config option. You
> can say that, "sure they can pull the patch from here and enable it
> anyway" or "they can figure it out and do it themselves, it's easy",
> but I do think there's a significant difference between being able to
> build a custom kernel with a configuration enabled vs being able to
> find and apply a random patch to a kernel and get it building and
> working. That's a different level of expertise. And going through that
> effort gives a person some time to reflect and think about if it
> should be done in the first place.
> 
> Adding this code to mainline makes it a feature of Linux and this
> driver. There's no way around that argument. Saying that "this is
> almost certainly not going to be used by regular end-users" is both
> fairly true as well as disingenuous. You're still making it an
> accepted feature.

Indeed. I had my concerns back when the CFG80211_CERTIFICATION_ONUS was
added to the kernel, but that is water under the bridge. It is not only
these kind of changes the FCC is looking at. They also have issues with
802.11d support. That does not even need a custom kernel. The end-user
just sets the country to some nice EU channel while being in the US and
screw up some weather radar. It has happened. Not life-threatening,
unless some tornado was missed maybe, but the concern is justified. How
the FCC is handling it may indeed be pointless and technically
misinformed, but that is because there is no good solution right now. At
least not a solution that assures it will not happen. I can only agree
that we as a community should not accommodate such (ab)use. Finding a
solution that is working for everyone is indeed the real challenge.

Regards,
Arend

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Arend Van Spriel]

On 12-5-2017 21:21, Steve deRosier wrote:
> Hi Ben,
> 
> On Fri, May 12, 2017 at 7:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 05/11/2017 04:38 AM, Kalle Valo wrote:
>>>

[snip]

>>> o I don't know about other countries, but in Finland applying for any
>>>   type of license (even if just to a license to drive a moped) needs
>>>   both time and money. So there is significant effort anyway needed to
>>>   legally use this band. And how many users there really are is unclear.
>>
>>
>> This is almost certainly not going to be used by regular end-users.  It is
>> going to be
>> used by public safety organizations who are buying equipment from companies
>> using open-wrt, LEDE, or similar, or possibly small teams at public safety
>> organizations doing the work themselves.  Rather than having each of these
>> vendors
> 
> I agree 100% that this won't be used by "regular end-users", if you
> define those users as the 99% of the population who will go to Best
> Buy and buy a router, plug it into their network and use it to get
> their iOS updates and download movies from Netflix. These aren't the
> users that the FCC is worried about.  They're concerned about the user
> who buys an OpenWRT compatible router, installs OpenWRT on it, builds
> a custom kernel. And that person happens to live in an area with
> congested WiFi bands, the person notices an option to use these other
> non-congested bands, decides that ignoring the warning would be
> harmless and the FCC won't ever know anyway.
> 
> And then there's a fire or other event in the area, and the emergency
> workers can't communicate. At best case, the FCC investigates and
> slaps a $25,000 fine on the operator. At worst case, someone dies.
> 
> I don't feel it's responsible as an engineer to hide behind "well, we
> warned them that they shouldn't do that" while ignoring my culpability
> in the matter. Setting the stage for others to fail due to their
> ignorance is not ethical.

Totally agree this is about being responsible.

> Anyone building a custom kernel is able to enable a config option. You
> can say that, "sure they can pull the patch from here and enable it
> anyway" or "they can figure it out and do it themselves, it's easy",
> but I do think there's a significant difference between being able to
> build a custom kernel with a configuration enabled vs being able to
> find and apply a random patch to a kernel and get it building and
> working. That's a different level of expertise. And going through that
> effort gives a person some time to reflect and think about if it
> should be done in the first place.
> 
> Adding this code to mainline makes it a feature of Linux and this
> driver. There's no way around that argument. Saying that "this is
> almost certainly not going to be used by regular end-users" is both
> fairly true as well as disingenuous. You're still making it an
> accepted feature.

Indeed. I had my concerns back when the CFG80211_CERTIFICATION_ONUS was
added to the kernel, but that is water under the bridge. It is not only
these kind of changes the FCC is looking at. They also have issues with
802.11d support. That does not even need a custom kernel. The end-user
just sets the country to some nice EU channel while being in the US and
screw up some weather radar. It has happened. Not life-threatening,
unless some tornado was missed maybe, but the concern is justified. How
the FCC is handling it may indeed be pointless and technically
misinformed, but that is because there is no good solution right now. At
least not a solution that assures it will not happen. I can only agree
that we as a community should not accommodate such (ab)use. Finding a
solution that is working for everyone is indeed the real challenge.

Regards,
Arend

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 2/3] ath10k: add support for channels in licensed bands

[Simon Wunderlich]

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

This patch also re-introduces the phy_mode_to_band function to allow
selecting the band in a more clean way.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
---
Changes to PATCHv1:
     * re-introduce and clean up phy to mode conversion (thanks Sebastian)
---
 drivers/net/wireless/ath/ath10k/Kconfig | 20 +++++++++++++
 drivers/net/wireless/ath/ath10k/core.h  |  4 +++
 drivers/net/wireless/ath/ath10k/mac.c   | 10 +++++++
 drivers/net/wireless/ath/ath10k/wmi.c   | 53 +++++++++++++++++++++++----------
 4 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig b/drivers/net/wireless/ath/ath10k/Kconfig
index b4241cf9b7ed..13a23ed33f91 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -53,3 +53,23 @@ config ATH10K_DFS_CERTIFIED
 	---help---
 	This option enables DFS support for initiating radiation on
 	ath10k.
+
+config ATH10K_LICENSED_CHAN
+	bool "Support channels in licensed bands"
+	depends on ATH10K && CFG80211_CERTIFICATION_ONUS
+	default n
+	---help---
+	  This option enables support for licensed channels on such as
+          4.9 GHz (public safety).
+
+	  These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+	  regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+	  your local radio regulator, e.g. the FCC or equivalent. Using these
+	  channels without proper authorisation may result in serious legal
+	  consequences.
+
+	  You will also have to build a regulatory database with these channels
+	  enabled to actually use them.
+
+	  If you are a distro kernel builder or have any doubt whatsoever about
+	  your legal ability to use these channels, say N.
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index d4b9a0ec1bdc..7674641537b4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,11 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+#define ATH10K_NUM_CHANS 47
+#else
 #define ATH10K_NUM_CHANS 40
+#endif
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d60086cdc584..81848e0a3a5e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7669,6 +7669,16 @@ static const struct ieee80211_channel ath10k_5ghz_channels[] = {
 	CHAN5G(161, 5805, 0),
 	CHAN5G(165, 5825, 0),
 	CHAN5G(169, 5845, 0),
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+	CHAN5G(184, 4920, 0),
+	CHAN5G(188, 4940, 0),
+	CHAN5G(192, 4960, 0),
+	CHAN5G(196, 4980, 0),
+	CHAN5G(8,   5040, 0),
+	CHAN5G(12,  5060, 0),
+	CHAN5G(16,  5080, 0),
+#endif
+
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4e60caec7ab4..d78c778eae4c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2271,6 +2271,41 @@ static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
 	return true;
 }
 
+static inline enum nl80211_band phy_mode_to_band(u32 phy_mode, u32 channel)
+{
+	enum nl80211_band band;
+
+	switch (phy_mode) {
+	case MODE_11A:
+	case MODE_11NA_HT20:
+	case MODE_11NA_HT40:
+	case MODE_11AC_VHT20:
+	case MODE_11AC_VHT40:
+	case MODE_11AC_VHT80:
+		band = NL80211_BAND_5GHZ;
+	break;
+	case MODE_11B:
+		/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is
+		 * set to MODE_11B.
+		 */
+		if (channel < 1 || channel > 14) {
+			band = NL80211_BAND_5GHZ;
+			break;
+		}
+	case MODE_11G:
+	case MODE_11GONLY:
+	case MODE_11NG_HT20:
+	case MODE_11NG_HT40:
+	case MODE_11AC_VHT20_2G:
+	case MODE_11AC_VHT40_2G:
+	case MODE_11AC_VHT80_2G:
+	default:
+		band = NL80211_BAND_2GHZ;
+	}
+
+	return band;
+}
+
 int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_mgmt_rx_ev_arg arg = {};
@@ -2320,22 +2355,8 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 			__le64_to_cpu(arg.ext_info.rx_mac_timestamp);
 		status->flag |= RX_FLAG_MACTIME_END;
 	}
-	/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
-	 * MODE_11B. This means phy_mode is not a reliable source for the band
-	 * of mgmt rx.
-	 */
-	if (channel >= 1 && channel <= 14) {
-		status->band = NL80211_BAND_2GHZ;
-	} else if (channel >= 36 && channel <= 169) {
-		status->band = NL80211_BAND_5GHZ;
-	} else {
-		/* Shouldn't happen unless list of advertised channels to
-		 * mac80211 has been changed.
-		 */
-		WARN_ON_ONCE(1);
-		dev_kfree_skb(skb);
-		return 0;
-	}
+
+	status->band = phy_mode_to_band(phy_mode, channel);
 
 	if (phy_mode == MODE_11B && status->band == NL80211_BAND_5GHZ)
 		ath10k_dbg(ar, ATH10K_DBG_MGMT, "wmi mgmt rx 11b (CCK) on 5GHz\n");
-- 
2.11.0

[PATCH v2 2/3] ath10k: add support for channels in licensed bands

[Simon Wunderlich]

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

This patch also re-introduces the phy_mode_to_band function to allow
selecting the band in a more clean way.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
---
Changes to PATCHv1:
     * re-introduce and clean up phy to mode conversion (thanks Sebastian)
---
 drivers/net/wireless/ath/ath10k/Kconfig | 20 +++++++++++++
 drivers/net/wireless/ath/ath10k/core.h  |  4 +++
 drivers/net/wireless/ath/ath10k/mac.c   | 10 +++++++
 drivers/net/wireless/ath/ath10k/wmi.c   | 53 +++++++++++++++++++++++----------
 4 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig b/drivers/net/wireless/ath/ath10k/Kconfig
index b4241cf9b7ed..13a23ed33f91 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -53,3 +53,23 @@ config ATH10K_DFS_CERTIFIED
 	---help---
 	This option enables DFS support for initiating radiation on
 	ath10k.
+
+config ATH10K_LICENSED_CHAN
+	bool "Support channels in licensed bands"
+	depends on ATH10K && CFG80211_CERTIFICATION_ONUS
+	default n
+	---help---
+	  This option enables support for licensed channels on such as
+          4.9 GHz (public safety).
+
+	  These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+	  regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+	  your local radio regulator, e.g. the FCC or equivalent. Using these
+	  channels without proper authorisation may result in serious legal
+	  consequences.
+
+	  You will also have to build a regulatory database with these channels
+	  enabled to actually use them.
+
+	  If you are a distro kernel builder or have any doubt whatsoever about
+	  your legal ability to use these channels, say N.
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index d4b9a0ec1bdc..7674641537b4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,11 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+#define ATH10K_NUM_CHANS 47
+#else
 #define ATH10K_NUM_CHANS 40
+#endif
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d60086cdc584..81848e0a3a5e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7669,6 +7669,16 @@ static const struct ieee80211_channel ath10k_5ghz_channels[] = {
 	CHAN5G(161, 5805, 0),
 	CHAN5G(165, 5825, 0),
 	CHAN5G(169, 5845, 0),
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+	CHAN5G(184, 4920, 0),
+	CHAN5G(188, 4940, 0),
+	CHAN5G(192, 4960, 0),
+	CHAN5G(196, 4980, 0),
+	CHAN5G(8,   5040, 0),
+	CHAN5G(12,  5060, 0),
+	CHAN5G(16,  5080, 0),
+#endif
+
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4e60caec7ab4..d78c778eae4c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2271,6 +2271,41 @@ static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
 	return true;
 }
 
+static inline enum nl80211_band phy_mode_to_band(u32 phy_mode, u32 channel)
+{
+	enum nl80211_band band;
+
+	switch (phy_mode) {
+	case MODE_11A:
+	case MODE_11NA_HT20:
+	case MODE_11NA_HT40:
+	case MODE_11AC_VHT20:
+	case MODE_11AC_VHT40:
+	case MODE_11AC_VHT80:
+		band = NL80211_BAND_5GHZ;
+	break;
+	case MODE_11B:
+		/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is
+		 * set to MODE_11B.
+		 */
+		if (channel < 1 || channel > 14) {
+			band = NL80211_BAND_5GHZ;
+			break;
+		}
+	case MODE_11G:
+	case MODE_11GONLY:
+	case MODE_11NG_HT20:
+	case MODE_11NG_HT40:
+	case MODE_11AC_VHT20_2G:
+	case MODE_11AC_VHT40_2G:
+	case MODE_11AC_VHT80_2G:
+	default:
+		band = NL80211_BAND_2GHZ;
+	}
+
+	return band;
+}
+
 int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct wmi_mgmt_rx_ev_arg arg = {};
@@ -2320,22 +2355,8 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 			__le64_to_cpu(arg.ext_info.rx_mac_timestamp);
 		status->flag |= RX_FLAG_MACTIME_END;
 	}
-	/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
-	 * MODE_11B. This means phy_mode is not a reliable source for the band
-	 * of mgmt rx.
-	 */
-	if (channel >= 1 && channel <= 14) {
-		status->band = NL80211_BAND_2GHZ;
-	} else if (channel >= 36 && channel <= 169) {
-		status->band = NL80211_BAND_5GHZ;
-	} else {
-		/* Shouldn't happen unless list of advertised channels to
-		 * mac80211 has been changed.
-		 */
-		WARN_ON_ONCE(1);
-		dev_kfree_skb(skb);
-		return 0;
-	}
+
+	status->band = phy_mode_to_band(phy_mode, channel);
 
 	if (phy_mode == MODE_11B && status->band == NL80211_BAND_5GHZ)
 		ath10k_dbg(ar, ATH10K_DBG_MGMT, "wmi mgmt rx 11b (CCK) on 5GHz\n");
-- 
2.11.0


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH v2 3/3] ath9k: add noise floor override option

[Simon Wunderlich]

Introduce a debugfs option to manually override the noise floor,
ignoring the automatically tuned noise floor of the driver/hw.

In my tests with a AR9580 based module and a tx99 5 MHz interferer,
I could tune the noisefloor to -95 dBm or above to allow communication
again. The automatic noise floor calibration sometimes could adapt to
the situation as well, but not reliably and permanently.

I would consider this "feature" experimental and interesting for people
debugging the noise floor calibration or other effects of the hardware.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath9k/calib.c |  5 ++-
 drivers/net/wireless/ath/ath9k/debug.c | 62 ++++++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/hw.h    |  1 +
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 0f71146b781d..13ab6bc46775 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -254,7 +254,9 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan)
 			if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
 				continue;
 
-			if (h)
+			if (ah->nf_override)
+				nfval = ah->nf_override;
+			else if (h)
 				nfval = h[i].privNF;
 			else
 				nfval = default_nf;
@@ -348,6 +350,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan)
 
 	return 0;
 }
+EXPORT_SYMBOL(ath9k_hw_loadnf);
 
 
 static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 43930c336987..2e64977a8ab6 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1191,6 +1191,65 @@ static const struct file_operations fops_tpc = {
 	.llseek = default_llseek,
 };
 
+static ssize_t read_file_nf_override(struct file *file,
+				     char __user *user_buf,
+				     size_t count, loff_t *ppos)
+{
+	struct ath_softc *sc = file->private_data;
+	struct ath_hw *ah = sc->sc_ah;
+	char buf[32];
+	unsigned int len;
+
+	if (ah->nf_override == 0)
+		len = sprintf(buf, "off\n");
+	else
+		len = sprintf(buf, "%d\n", ah->nf_override);
+
+	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_nf_override(struct file *file,
+				      const char __user *user_buf,
+				      size_t count, loff_t *ppos)
+{
+	struct ath_softc *sc = file->private_data;
+	struct ath_hw *ah = sc->sc_ah;
+	long val;
+	char buf[32];
+	ssize_t len;
+
+	len = min(count, sizeof(buf) - 1);
+	if (copy_from_user(buf, user_buf, len))
+		return -EFAULT;
+
+	buf[len] = '\0';
+	if (strncmp("off", buf, 3) == 0)
+		val = 0;
+	else if (kstrtol(buf, 0, &val))
+		return -EINVAL;
+
+	if (val > 0)
+		return -EINVAL;
+
+	if (val < -120)
+		return -EINVAL;
+
+	ah->nf_override = val;
+
+	if (ah->curchan)
+		ath9k_hw_loadnf(ah, ah->curchan);
+
+	return count;
+}
+
+static const struct file_operations fops_nf_override = {
+	.read = read_file_nf_override,
+	.write = write_file_nf_override,
+	.open = simple_open,
+	.owner = THIS_MODULE,
+	.llseek = default_llseek,
+};
+
 /* Ethtool support for get-stats */
 
 #define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
@@ -1402,5 +1461,8 @@ int ath9k_init_debug(struct ath_hw *ah)
 	debugfs_create_u16("airtime_flags", S_IRUSR | S_IWUSR,
 			   sc->debug.debugfs_phy, &sc->airtime_flags);
 
+	debugfs_create_file("nf_override", S_IRUSR | S_IWUSR,
+			    sc->debug.debugfs_phy, sc, &fops_nf_override);
+
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 2166f644599d..f06e02d1c342 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -807,6 +807,7 @@ struct ath_hw {
 	u32 rfkill_gpio;
 	u32 rfkill_polarity;
 	u32 ah_flags;
+	s16 nf_override;
 
 	bool reset_power_on;
 	bool htc_reset_init;
-- 
2.11.0

[PATCH v2 3/3] ath9k: add noise floor override option

[Simon Wunderlich]

Introduce a debugfs option to manually override the noise floor,
ignoring the automatically tuned noise floor of the driver/hw.

In my tests with a AR9580 based module and a tx99 5 MHz interferer,
I could tune the noisefloor to -95 dBm or above to allow communication
again. The automatic noise floor calibration sometimes could adapt to
the situation as well, but not reliably and permanently.

I would consider this "feature" experimental and interesting for people
debugging the noise floor calibration or other effects of the hardware.

Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath9k/calib.c |  5 ++-
 drivers/net/wireless/ath/ath9k/debug.c | 62 ++++++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/hw.h    |  1 +
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c b/drivers/net/wireless/ath/ath9k/calib.c
index 0f71146b781d..13ab6bc46775 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -254,7 +254,9 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan)
 			if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
 				continue;
 
-			if (h)
+			if (ah->nf_override)
+				nfval = ah->nf_override;
+			else if (h)
 				nfval = h[i].privNF;
 			else
 				nfval = default_nf;
@@ -348,6 +350,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel *chan)
 
 	return 0;
 }
+EXPORT_SYMBOL(ath9k_hw_loadnf);
 
 
 static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 43930c336987..2e64977a8ab6 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1191,6 +1191,65 @@ static const struct file_operations fops_tpc = {
 	.llseek = default_llseek,
 };
 
+static ssize_t read_file_nf_override(struct file *file,
+				     char __user *user_buf,
+				     size_t count, loff_t *ppos)
+{
+	struct ath_softc *sc = file->private_data;
+	struct ath_hw *ah = sc->sc_ah;
+	char buf[32];
+	unsigned int len;
+
+	if (ah->nf_override == 0)
+		len = sprintf(buf, "off\n");
+	else
+		len = sprintf(buf, "%d\n", ah->nf_override);
+
+	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_nf_override(struct file *file,
+				      const char __user *user_buf,
+				      size_t count, loff_t *ppos)
+{
+	struct ath_softc *sc = file->private_data;
+	struct ath_hw *ah = sc->sc_ah;
+	long val;
+	char buf[32];
+	ssize_t len;
+
+	len = min(count, sizeof(buf) - 1);
+	if (copy_from_user(buf, user_buf, len))
+		return -EFAULT;
+
+	buf[len] = '\0';
+	if (strncmp("off", buf, 3) == 0)
+		val = 0;
+	else if (kstrtol(buf, 0, &val))
+		return -EINVAL;
+
+	if (val > 0)
+		return -EINVAL;
+
+	if (val < -120)
+		return -EINVAL;
+
+	ah->nf_override = val;
+
+	if (ah->curchan)
+		ath9k_hw_loadnf(ah, ah->curchan);
+
+	return count;
+}
+
+static const struct file_operations fops_nf_override = {
+	.read = read_file_nf_override,
+	.write = write_file_nf_override,
+	.open = simple_open,
+	.owner = THIS_MODULE,
+	.llseek = default_llseek,
+};
+
 /* Ethtool support for get-stats */
 
 #define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
@@ -1402,5 +1461,8 @@ int ath9k_init_debug(struct ath_hw *ah)
 	debugfs_create_u16("airtime_flags", S_IRUSR | S_IWUSR,
 			   sc->debug.debugfs_phy, &sc->airtime_flags);
 
+	debugfs_create_file("nf_override", S_IRUSR | S_IWUSR,
+			    sc->debug.debugfs_phy, sc, &fops_nf_override);
+
 	return 0;
 }
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 2166f644599d..f06e02d1c342 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -807,6 +807,7 @@ struct ath_hw {
 	u32 rfkill_gpio;
 	u32 rfkill_polarity;
 	u32 ah_flags;
+	s16 nf_override;
 
 	bool reset_power_on;
 	bool htc_reset_init;
-- 
2.11.0


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [v2,3/3] ath9k: add noise floor override option

[Kalle Valo]

Simon Wunderlich <sw@simonwunderlich.de> wrote:
> Introduce a debugfs option to manually override the noise floor,
> ignoring the automatically tuned noise floor of the driver/hw.
> 
> In my tests with a AR9580 based module and a tx99 5 MHz interferer,
> I could tune the noisefloor to -95 dBm or above to allow communication
> again. The automatic noise floor calibration sometimes could adapt to
> the situation as well, but not reliably and permanently.
> 
> I would consider this "feature" experimental and interesting for people
> debugging the noise floor calibration or other effects of the hardware.
> 
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>

Patch applied to ath-next branch of ath.git, thanks.

b90189759a7f ath9k: add noise floor override option

-- 
https://patchwork.kernel.org/patch/9641107/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [v2,3/3] ath9k: add noise floor override option

[Kalle Valo]

Simon Wunderlich <sw@simonwunderlich.de> wrote:
> Introduce a debugfs option to manually override the noise floor,
> ignoring the automatically tuned noise floor of the driver/hw.
> 
> In my tests with a AR9580 based module and a tx99 5 MHz interferer,
> I could tune the noisefloor to -95 dBm or above to allow communication
> again. The automatic noise floor calibration sometimes could adapt to
> the situation as well, but not reliably and permanently.
> 
> I would consider this "feature" experimental and interesting for people
> debugging the noise floor calibration or other effects of the hardware.
> 
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>

Patch applied to ath-next branch of ath.git, thanks.

b90189759a7f ath9k: add noise floor override option

-- 
https://patchwork.kernel.org/patch/9641107/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k