Re: [PATCH] ath9k: Fix a WARNING in suspend/resume with IBSS

[Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>]

Hi Johannes,


>>>>> You could just remove the entire check since the interface combinations
>>>>> you advertise don't allow it, I think? Or just fix those
>>>>> combinations :-)
>>>>
>>>> i did not check this before, thanks a lot for your inputs. will send a
>>>> proper v2 after checking this out.
>>>
>>> If this is needed for stable, you might want to keep this patch&   send
>>> another one to remove it.
>>
>> thanks Johannes.
>> i was looking at how to fix this properly in iface combination
>> advertised to mac80211.  got few doubts regarding this
>>
>> *if an interface type is not all advertised in the
>> ieee80211_iface_combination then it cannot it be co-existing with any
>> other interfaces ?
>> please let me know is there some other way do that.
>>
>> if we advertise something like this
>>
>> static const struct ieee80211_iface_limit if_limits[] = {
>> 	{set1
>>       	.... },
>> 	{set 2
>> 	.... },
>> };
>>
>> then interface types in set1 and set2 co-exist as per the logic in
>> cfg80211_can_change_interface. is there already a way we can make
>> set1 and set2 interface types mutually exclusive ? thanks!
>
> The sets are mutually exclusive, and there are implied sets of each
> interface with a max number of 1. So for example, in iwlwifi we don't
> advertise IBSS in the combinations at all, because it's not compatible
> with anything. In your case, I think the same applies, since you said
>
>          if the first interface is ADHOC we cannot have any other
>          interface. we cannot add an ADHOC interface if there is already
>          an interface is present
>
> Thus, if you leave IBSS out of the combinations you should get the
> desired behaviour of not being able to combine IBSS with any other
> types.
>

ath9k and also iwlwifi seems to have IBSS check not included in any of 
the interface combinations, but still i am able to IBSS interface 
atleast in ath9k with the checks removed in drv_add_interface.
it seems we are allowing any interface type to be added even if
its not added in the ieee80211_iface_combination structure.

i am sending an RFC to add this check in cfg80211 based on my 
understanding. please review my understanding and any corrections
needed. thanks for your thoughts!

-- 
thanks,
shafi