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@xxxxxxxxxxxxxxxxxx> wrote: > > Hi, > > On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote: > > Simon Wunderlich <sw@xxxxxxxxxxxxxxxxxx> wrote: > > > From: Ben Greear <greearb@xxxxxxxxxxxxxxx> > > > > > > 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.
