On Thu, Oct 6, 2011 at 2:08 PM, Zefir Kurtisi <zefir.kurtisi@xxxxxxxxxxx> wrote: > On 06.10.2011 22:41, Luis R. Rodriguez wrote: >> On Thu, Oct 6, 2011 at 1:32 PM, Zefir Kurtisi<zefir.kurtisi@xxxxxxxxxxx> 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. Ah yeah great point. I punted internally to see if there was a EEPROM bit we can read that may tell us if a card is DFS certified. If that is not available I think what we can do is leave the option but set the default to disabled and simply state that only platforms that have passed DFS certification should have it enabled. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
