On Fri, 2024-06-07 at 11:53 +0200, Felix Fietkau wrote:
> > struct wiphy_radio *wiphy_get_radio(struct wiphy *wiphy, ... *chandef);
>
> I didn't add such a helper, in case we get hardware where multiple
> radios support the same band. That's why ieee80211_find_available_radio
> loops over all radios until it finds one that matches both the freq
> range and the ifcomb constraints.
Ah, fair.
Thinking more about the "whole chandef" thing, I think I want to have a
check in cfg80211 somewhere that ensures you don't split up ranges that
could be used for a wider channel?
Say (for a stupid example) you have a device that (only) supports
channels 36-40:
* 5180
* 5200
but now you say it has two radios:
* radio 1 ranges: 5170-5190
* radio 2 ranges: 5190-5210
Now you can't use 40 MHz... but nothing will actually really prevent it.
Obviously this is a totally useless case, so I'd argue we should just
check during wiphy registration that you don't split the channel list in
this way with multiple radios?
Even on the potential Qualcomm 5 GHz low/mid/high split radios you'd
have gaps between the channels (e.g. no channel 80, no channel 148), so
it feels like you should always be able to split it in a way that the
radio range boundaries don't land between two adjacent channels in the
channel array.
Not sure how to implement such a check best, probably easiest to find
all non-adjacent channels first:
- go over bands
- ensure channels are sorted by increasing frequency
(not sure we do that today? but every driver probably does)
- find adjacent channels:
- while more channels:
- start_freq = current channel's freq - 10
- end_freq = current channel's freq + 10
- while current channel's freq == end_freq - 10:
- go to next channel
- check all radio's ranges cover this full or not at all
(neither start nor end of a range falls into the calculated
[start_freq, end_freq) interval)
or something like that?
(Also some docs on this I guess!)
johannes
