On 2 March 2015 at 11:17, Vasanthakumar Thiagarajan
<vthiagar@xxxxxxxxxxxxxxxx> wrote:
[...]
>>> +{
>>> + struct ath10k_vif *arvif;
>>> +
>>> + if (!ar->num_started_vdevs)
>>> + return false;
>>> +
>>> + list_for_each_entry(arvif, &ar->arvifs, list) {
>>
>>
>> This means function must be called while holding conf_mutex (my MCC
>> patch adds data_lock as an option, but current upstream tree uses
>> conf_mutex only).
>
>
> Ok. Sure, we can fix it when we have MCC change into the tree.
No need. With the way ath10k_monitor_recalc() is called it makes sense
to rely on lockdep_assert_held(ar->conf_mutex) only.
The data_lock was just FYI.
>>> @@ -3476,6 +3504,13 @@ static void ath10k_configure_filter(struct
>>> ieee80211_hw *hw,
>>>
>>> changed_flags &= SUPPORTED_FILTERS;
>>> *total_flags &= SUPPORTED_FILTERS;
>>> + if (*total_flags & FIF_PROMISC_IN_BSS) {
>>> + if (ar->num_started_vdevs) {
>>> + ath10k_dbg(ar, ATH10K_DBG_MAC,
>>> + "mac does not enable promiscuous mode
>>> when already a vdev is running\n");
>>> + *total_flags &= ~FIF_PROMISC_IN_BSS;
>>> + }
>>> + }
>>
>>
>> There's no need for that, is there? The monitor_recalc() is supposed
>> to deal with this.
>
>
> Right, but we may not want to create any inconsistencies between
> *total_flags and actual
> filters enabled in the driver?.
See the "DOC: Frame filtering" in include/net/mac80211.h. ath10k
either always delivers frames IN_BSS (AP operation) or can be forced
to (via monitor vdev for STA/IBSS operation) so FIF_PROMISC_IN_BSS
should never be cleared.
Michał
--
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
