Received-SPF: pass (google.com: domain of linux-wireless+bounces-8604-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <f751d310-4cbb-4562-947b-a0a76edb6b40@quicinc.com>
Date: Thu, 6 Jun 2024 15:30:03 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC v2 0/7] cfg80211/mac80211: support defining multiple radios
 per wiphy
To: Felix Fietkau <nbd@nbd.name>, <linux-wireless@vger.kernel.org>
CC: <johannes@sipsolutions.net>, <quic_periyasa@quicinc.com>,
        <ath12k@lists.infradead.org>
References: <cover.c104c0bb3a14f4ac26aee71f4979846f6ad87742.1717611760.git-series.nbd@nbd.name>
Content-Language: en-US
From: Aditya Kumar Singh <quic_adisi@quicinc.com>
In-Reply-To: <cover.c104c0bb3a14f4ac26aee71f4979846f6ad87742.1717611760.git-series.nbd@nbd.name>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

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?