On Mar 4, 2010, at 9:31 AM, Luis R. Rodriguez wrote:
> On Thu, Mar 4, 2010 at 2:24 AM, Daniel Halperin
> <dhalperi@xxxxxxxxxxxxxxxxx> wrote:
>> On Mar 3, 2010, at 2:54 PM, Daniel Halperin wrote:
>
>> My hypothesis as to why this code used to work is that I was using the CONFIG_WIRELESS_OLD_REGULATORY.
>
> Can you test the same by disabling CONFIG_WIRELESS_OLD_REGULATORY ?
I am no longer using CONFIG_WIRELESS_OLD_REGULATORY; in fact I believe that kernel option has been removed. I don't have any old versions around any more unfortunately to test this hypothesis with.
> There is a way for a driver to claim a custom world regulatory domain,
> this can be done wiphy_apply_custom_regulatory(), ath/regd.c uses
> that. Otherwise indeed the pegged regulatory domain will be used as a
> basis for disabling further channels.
It turns out that disabling WIPHY_FLAG_STRICT_REGULATORY:
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2632,7 +2632,7 @@ static int iwl_mac_setup_register(struct iwl_priv *priv)
BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC);
- hw->wiphy->flags |= WIPHY_FLAG_STRICT_REGULATORY |
+ hw->wiphy->flags |= //WIPHY_FLAG_STRICT_REGULATORY |
WIPHY_FLAG_DISABLE_BEACON_HINTS;
/*
also fixes the problem; in reality this is a hack. It does seem to keep the proper driver-set regulatory limits even when I switch modes or channels or CRDA domains. This is because iwl_mac_setup_register() happens after the eeprom is read in iwl-agn.c, and thus the regulatory flags (chan->orig_flags) are pegged and thus stay set properly throughout the run. But it seems like the right approach is actually to do what ath/regd.c does and apply the custom regulatory domain.
Right now, iwlwifi sets WIPHY_FLAG_STRICT_REGULATORY but never sends the custom regulatory domain and so all CRDA requests are ignored by the checks in <base>/net/wireless/reg.c:handle_channel. (Until iwlagn, but not cfg80211, is reloaded).
Dan--
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
