> 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:johannes@xxxxxxxxxxxxxxxx] Sent: Thursday, August 11, 2016 6:39 PM To: Kushwaha, Purushottam <pkushwah@xxxxxxxxxxxxxxxx> Cc: linux-wireless@xxxxxxxxxxxxxxx; Malinen, Jouni <jouni@xxxxxxxxxxxxxxxx>; Undekari, Sunil Dutt <usdutt@xxxxxxxxxxxxxxxx>; Hullur Subramanyam, Amarnath <amarnath@xxxxxxxxxxxxxxxx>; Kumar, Deepak (QCA) <djindal@xxxxxxxxxxxxxxxx> 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��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
