>In order to validate a new beacon interval, you're first looking up the min GCD value of all the combinations that allow the *current* scenario, but doing that matching without the right # of channels or >radar detect parameters? And then you're trying to match that to the new beacon interval?
Yes . Please allow us to explain the rationale for doing so.
1. The intention here is to ensure that the beacon interval configured for any single interface is greater than the "diff_beacon_int_gcd_min" specified in the respective combinations.
2. Since "diff_beacon_int_gcd_min" is only specified / advertised in the interface combinations , our logic was to get the minimal "diff_beacon_int_gcd_min" of all the matching combinations and later
compare with the new beacon interval. (API "cfg80211_iter_combinations" has to be invoked to get the corresponding "diff_beacon_int_gcd_min")
3. If the beacon interval configured needs to be ensured to be greater than the "diff_beacon_int_gcd_min" configured for both the "single interface" and "interface combination" , we have resorted to
"2" (get the minimal of "diff_beacon_int_gcd_min" among all the matched interface combinations and then compare it with the configured beacon interval).
>If the driver specified diff_beacon_int_gcd_min, then don't do anything in cfg80211_validate_beacon_int(), other than perhaps a minimal range check against the minimum of all >diff_beacon_int_gcd_min values for all combinations.
> That new argument could be made the GCD of all existing beaconing interfaces (or 0 if no such exists), since that's sufficient for checking against a new min_gcd.
If I understand this correctly , are you saying that this new argument to cfg80211_iter_combinations shall be the GCD of all the existing beacon intervals and would be used to match with the corresponding "diff_beacon_int_gcd_min" of the interface combinations in "cfg80211_iter_combinations".
If yes , this GCD argument does not represent , if the beacon intervals of all the existing interfaces differ or not , isn’t ? If the "diff_beacon_int_gcd_min" of the all the matching interface combinations is 0 , such differed beacon intervals would pass the check , contradicting the existing logic ( not allowing the differed beacon intervals), isn't ?
Thus, wouldn't it be a better option to first get the "diff_beacon_int_gcd_min" advertised by the respective interface combinations and then later compare it with the configured / calculated beacon
interval's GCD .
Also , not quite sure how would your comment " matching without the right # of channels or radar detect parameters" get addressed with your new proposal ( adding a new argument to "cfg80211_iter_combinations" )
Regards,
Sunil
-----Original Message-----
From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx]
Sent: Monday, September 12, 2016 3:54 PM
To: Kushwaha, Purushottam <pkushwah@xxxxxxxxxxxxxxxx>
Cc: linux-wireless@xxxxxxxxxxxxxxx; Malinen, Jouni <jouni@xxxxxxxxxxxxxxxx>; Undekari, Sunil Dutt <usdutt@xxxxxxxxxxxxxxxx>; Hullur Subramanyam, Amarnath <amarnath@xxxxxxxxxxxxxxxx>
Subject: Re: [PATCH v8] cfg80211: Provision to allow the support for different beacon intervals
Hmm. Apart from some misleading documentation, that doesn't mention "GCD" at all, the logic seems odd.
In order to validate a new beacon interval, you're first looking up the min GCD value of all the combinations that allow the *current* scenario, but doing that matching without the right # of channels or radar detect parameters? And then you're trying to match that to the new beacon interval?
It seems to me that the logic should be something like:
If the driver specified diff_beacon_int_gcd_min, then don't do anything in cfg80211_validate_beacon_int(), other than perhaps a minimal range check against the minimum of all diff_beacon_int_gcd_min values for all combinations.
Then, add a new argument to cfg80211_check_combinations() (and
cfg80211_iter_combinations()) to have the beacon intervals for each beaconing interface, and use that in order to match if a combination fits, inside cfg80211_iter_combinations().
That new argument could be made the GCD of all existing beaconing interfaces (or 0 if no such exists), since that's sufficient for checking against a new min_gcd.
johannes
