On 15/10/14 3:59 am, "Sujith Manoharan" <[email protected]> wrote:
>MCC is currently used in CUS227, an Allplay >device. Since audio streaming will be affected >with long offchannel periods, reduce the max. >offchannel duration to 200ms. >diff --git a/drivers/net/wireless/ath/ath9k/init.c >b/drivers/net/wireless/ath/ath9k/init.c >@@ -789,7 +789,7 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, >struct ieee80211_hw *hw) >- hw->wiphy->max_remain_on_channel_duration = 10000; >+ hw->wiphy->max_remain_on_channel_duration = 200; This looks like a bad idea as the default value. Wouldn't this break a lot of use cases where longer wait is needed? Please keep in mind that remain-on-channel is used for non-P2P use cases as well and there are known P2P devices that won't be able to reply in 200 ms to messages in many cases. I would not reduce this value below 1000 ms and really, if there is need to reduce remain-on-channel operations while there is a concurrent connection, that should be done dynamically at runtime, e.g., in wpa_supplicant, rather than the driver hardcoding a very small maximum value. - Jouni -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
