Received-SPF: pass (google.com: domain of linux-wireless+bounces-7293-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <3dfdc7c9-ae1e-c6c4-9018-0b97aa26c37a@quicinc.com>
Date: Tue, 7 May 2024 21:05:29 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH RFC] wifi: cfg80211: Refactor interface combination input
 parameter
Content-Language: en-US
To: Johannes Berg <johannes@sipsolutions.net>
CC: <linux-wireless@vger.kernel.org>
References: <20240427031503.22870-1-quic_periyasa@quicinc.com>
 <3f8e4d6d0f2facde80ad82b5b3060eb0af0958a4.camel@sipsolutions.net>
From: Karthikeyan Periyasamy <quic_periyasa@quicinc.com>
In-Reply-To: <3f8e4d6d0f2facde80ad82b5b3060eb0af0958a4.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 5/7/2024 3:17 PM, Johannes Berg wrote:
> On Sat, 2024-04-27 at 08:45 +0530, Karthikeyan Periyasamy wrote:
>> Currently, the interface combination input parameter num_different_channels
>> and iftype_num are directly filled in by the caller under the assumption
>> that all channels and interfaces belong to a single hardware device. This
>> assumption is incorrect for multi-device interface combinations because
>> each device supports a different set of channels and interfaces. As
>> discussed in [1], need to refactor the input parameters to encode enough
>> data to handle both single and multiple device interface combinations.
>> This can be achieved by encoding the frequency and interface type under
>> the interface entity itself. With this new input parameter structure, the
>> cfg80211 can classify and construct the device parameters, then verify them
>> against the device specific interface combinations.

...

> 
>> +/**
>> + * struct iface_combination_iface_link - Interface combination link parameter
>> + *
>> + * Used to pass link specific interface combination parameters
>> + *
>> + * @freq: center frequency used for verification against the different channels
>> + */
>> +struct iface_combination_iface_link {
>> +	u32 freq;
>> +};
>> +
>> +/**
>> + * struct iface_combination_interface - Interface parameter for iface combination
>> + *
>> + * Used to pass interface specific parameter for iface combination
>> + *
>> + * @iftype: interface type as specified in &enum nl80211_iftype.
>> + * @links: array with the number of link parameter used for verification
>> + * @num_link: the length of the @links parameter used in this interface
>> + */
>> +struct iface_combination_interface {
>> +	enum nl80211_iftype iftype;
>> +	struct iface_combination_iface_link links[IEEE80211_MLD_MAX_NUM_LINKS];
>> +	u8 num_link;
> 
> Might be simpler (for the producers at least, but not really much more
> difficult for the consumer) to just remove num_link, use the link ID as
> the index, and declare freq==0 means unused?

Previously user able to check the iface combination with the new 
interface/channel creation independently with separate input parameter 
as below without knowing the frequency of the interface.

        params.num_different_channels = 1;

        for_each_vap(...)
              params.iftype_num[iftype]++;


when the user not aware of the channel but still they want to check the 
new channel creation possible scenario, in that case they just fill the 
dummy freq as zero and fill the num_link as 1 for all the interfaces.

So freq=0 is used here.


-- 
Karthikeyan Periyasamy
--
கார்த்திகேயன் பெரியசாமி