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

[Simon Wunderlich]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20170509/3f31c332/attachment.sig>