On 6/6/2024 2:28 PM, Felix Fietkau wrote:
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?
Our hardware supports radio aligned beacon interval.
Currently, ath12k use use same beacon interval configuration all radio
iface combination.
Even in radio specific iface combination, we should check the beacon
interval for the non MLO VAPs.
so dont avoid the beacon interval check.
--
Karthikeyan Periyasamy
--
கார்த்திகேயன் பெரியசாமி
