On 06.06.24 10:56, Karthikeyan Periyasamy wrote:
On 6/6/2024 1:25 PM, Felix Fietkau wrote:
On 06.06.24 09:20, Karthikeyan Periyasamy wrote:
On 6/6/2024 12:01 AM, Felix Fietkau wrote:
/*
* This is a bit strange, since the iteration used to rely only on
@@ -2384,8 +2383,10 @@ int cfg80211_iter_combinations(struct wiphy
*wiphy,
* cfg80211 already - the only thing not would appear to be any
new
* interfaces (while being brought up) and channel/radar data.
*/
- cfg80211_calculate_bi_data(wiphy, params->new_beacon_int,
- &beacon_int_gcd, &beacon_int_different);
+ if (!radio)
+ cfg80211_calculate_bi_data(wiphy, params->new_beacon_int,
+ &beacon_int_gcd,
+ &beacon_int_different);
Why its avoid for radio specific iface combination ?
Because it iterates over all wdevs within cfg80211. I didn't think this
was necessary, given that it already excludes MLO wdevs.
Dont tie the radio specific iface advertisement with MLO.
Usually the existing code consider "params->new_beacon_int" the MLO
scenario also.
For your hardware, do beacon intervals need to be matched/aligned per
radio or globally?
- Felix
