From: Zefir Kurtisi Date: Thu, 06 Oct 2011 23:08:43 +0200 Subject: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection In-Reply-To: References: <1317637758-11907-1-git-send-email-zefir.kurtisi@neratec.com> <201110041538.12885.chunkeey@googlemail.com> <201110061849.48838.chunkeey@googlemail.com> <4E8E1062.1070206@neratec.com> Message-ID: <4E8E18DB.5070002@neratec.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 06.10.2011 22:41, Luis R. Rodriguez wrote: > On Thu, Oct 6, 2011 at 1:32 PM, Zefir Kurtisi wrote: >> As said above, disabling a driver's capability through a Kconfig option >> should be enough (one ifdef per driver). > > OK cool. > >> Since regulatory compliance and open source by principle form a >> gray-zone combination [2], testing for sure is essential to keep it more >> white than black ;) >> >> [2] http://linuxwireless.org/en/developers/Regulatory/statement#Principles > > I actually do not think its grey now at all, we in fact IMHO have the > best regulatory framework out there, while still ensuring freedoms. > > Luis Sorry, of course it is, I was not specific enough. I was just wondering if principle 3 generally would prevent us from adding a Kconfig option to enable DFS for ath9k as long as it is not certified (which is the only way to ensure to have a 'known compliant usage') plus depending on mac80211 and hostapd. Zefir