>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:[email protected]]
Sent: Monday, September 12, 2016 3:54 PM
To: Kushwaha, Purushottam <[email protected]>
Cc: [email protected]; Malinen, Jouni <[email protected]>;
Undekari, Sunil Dutt <[email protected]>; Hullur Subramanyam, Amarnath
<[email protected]>
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
