Message ID | cover.c104c0bb3a14f4ac26aee71f4979846f6ad87742.1717611760.git-series.nbd@nbd.name (mailing list archive) |
---|---|
Headers | show |
Series | cfg80211/mac80211: support defining multiple radios per wiphy | expand |
On 6/6/24 00:01, Felix Fietkau wrote: > The prerequisite for MLO support in cfg80211/mac80211 is that all the links > participating in MLO must be from the same wiphy/ieee80211_hw. To meet this > expectation, some drivers may need to group multiple discrete hardware each > acting as a link in MLO under single wiphy. > > With this series, the bands and supported frequencies of each individual > radio are reported to user space. This allows user space to figure out the > limitations of what combination of channels can be used concurrently. > > Each mac80211 channel context is assigned to a radio based on radio specific > frequency ranges and interface combinations. > > This is loosely based on Karthikeyan Periyasamy's series > "[PATCH 00/13] wifi: Add multi physical hardware iface combination support" > with some differences: > > - a struct wiphy_radio is defined, which holds the frequency ranges and > a full struct ieee80211_iface_combination array > - a channel context is explicitly assigned to a radio when created > - both global and per-radio interface combination limits are checked > and enforced on channel context assignment > > Changes since RFC: > - replace static per-radio number of channels limit with full ifcomb > checks > - remove band bitmask in favor of only using freq ranges What about handling 2 GHz + 5 GHz issue we discussed in v1 related to radar detection width and num chan ctx? Is that taken care?
On 06.06.24 12:00, Aditya Kumar Singh wrote: > On 6/6/24 00:01, Felix Fietkau wrote: >> The prerequisite for MLO support in cfg80211/mac80211 is that all the links >> participating in MLO must be from the same wiphy/ieee80211_hw. To meet this >> expectation, some drivers may need to group multiple discrete hardware each >> acting as a link in MLO under single wiphy. >> >> With this series, the bands and supported frequencies of each individual >> radio are reported to user space. This allows user space to figure out the >> limitations of what combination of channels can be used concurrently. >> >> Each mac80211 channel context is assigned to a radio based on radio specific >> frequency ranges and interface combinations. >> >> This is loosely based on Karthikeyan Periyasamy's series >> "[PATCH 00/13] wifi: Add multi physical hardware iface combination support" >> with some differences: >> >> - a struct wiphy_radio is defined, which holds the frequency ranges and >> a full struct ieee80211_iface_combination array >> - a channel context is explicitly assigned to a radio when created >> - both global and per-radio interface combination limits are checked >> and enforced on channel context assignment >> >> Changes since RFC: >> - replace static per-radio number of channels limit with full ifcomb >> checks >> - remove band bitmask in favor of only using freq ranges > > What about handling 2 GHz + 5 GHz issue we discussed in v1 related to > radar detection width and num chan ctx? Is that taken care? Seems that I missed that one. I will take care of it in the next version. Thanks, - Felix