[PATCH V3 2/2] ath10k: Fix interrupt storm

[Michal Kazior]

On 2 March 2015 at 11:17, Vasanthakumar Thiagarajan
<vthiagar at qti.qualcomm.com> 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ł