> This seems odd. Shouldn't it use cfg80211_iter_combinations()? Yes . We should have reused cfg80211_iter_combinations. Thanks a lot for your suggestion.
> seems we mostly moved that to mac80211, but for this case it should probably > stay in cfg80211? Or should it? The scope here is to know the advertised "diff_beacon_int_gcd" for the respective matching interface combination and further validate it with the configured one. To address this " cfg80211_validate_beacon_int" needs to get enhanced , isn't ? Regards, Sunil -----Original Message----- From: Johannes Berg [mailto:[email protected]] Sent: Thursday, August 11, 2016 6:39 PM To: Kushwaha, Purushottam <[email protected]> Cc: [email protected]; Malinen, Jouni <[email protected]>; Undekari, Sunil Dutt <[email protected]>; Hullur Subramanyam, Amarnath <[email protected]>; Kumar, Deepak (QCA) <[email protected]> Subject: Re: [PATCH v5] cfg80211: Provision to allow the support for different beacon intervals > +static bool diff_beacon_interval_supported(struct wiphy *wiphy, u16 > types, > + u32 beacon_int) > +{ > + const struct ieee80211_iface_combination *c; > + u16 all_types; > + int i, j; > + > + for (i = 0; i < wiphy->n_iface_combinations; i++) { > + c = &wiphy->iface_combinations[i]; > + > + if (!c->diff_beacon_int_gcd || > + (beacon_int % c->diff_beacon_int_gcd)) > + continue; > + > + all_types = 0; > + for (j = 0; j < c->n_limits; j++) > + all_types |= c->limits[j].types; > + > + if (all_types & types) > + return true; > + } > + > + return false; > +} This seems odd. Shouldn't it use cfg80211_iter_combinations()? Might need some additional helper to understand which interface types are used right now - seems we mostly moved that to mac80211, but for this case it should probably stay in cfg80211? Or should it? johannes N�����r��y����b�X��ǧv�^�){.n�+����{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w��� ���j:+v���w�j�m��������zZ+�����ݢj"��!�i
