> -----Original Message----- > From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Sent: Monday, May 16, 2022 13:33 > To: Aditya Kumar Singh (QUIC) <quic_adisi@xxxxxxxxxxx>; linux- > wireless@xxxxxxxxxxxxxxx > Cc: Wen Gong <wgong@xxxxxxxxxxxxxx> > Subject: Re: [RFC] mac80211: add support for 6 GHz channels and regulatory > > WARNING: This email originated from outside of Qualcomm. Please be wary > of any links or attachments, and do not enable macros. > > Hi, > > On Mon, 2021-12-06 at 12:56 +0530, Aditya Kumar Singh wrote: > > 6 GHz introduces various power modes of operation. Currently, based on > > the power mode, channel's psd value as well as channel disabled flag > > can change. For single interface, current implementaion works just > > fine. But for multi-interfaces, for example AP-STA concurrency, two > > different channel needs to be maintained. This is because, STA power > > mode also depends on the AP's power mode it is going to associate > > with. Hence, psd value and channel disabled flag might vary. In this > > case, same channel can not be used for both AP and STA. > > > So ... you correctly point out that we need to deal with multiple interface > scenarios. > > But we had a previous/ongoing discussion: > https://lore.kernel.org/linux-wireless/20210928085211.26186-1- > wgong@xxxxxxxxxxxxxx/ > > > Hence, this patch adds support to store all possible 6 GHz channels > > according to power mode as well as add API support for getting > > chan/freq info from the new struct ieee80211_6ghz_channel. > > > > FWIW, I'm not sure that it's a good idea to have separate channel structs? > Wouldn't it make more sense to have each channel store separate relevant > information regarding the power? > I thought about this approach (let's call it Approach B) too, but the problem is if we store as you mentioned, then at every place where those ieee80211_channel members are used, we have to add condition to first check if freq in in 6 GHz band and then accordingly select the\ required member based on the power mode. The current approach was taken considering struct cfg80211_chan_def stores the ieee80211_channel directly and once we assign the correct ieee80211_channel from the available pool of ieee80211_channels, rest all things will automatically fall into its place. No further modification is required. Also, 6 GHz is still evolving, and until now we know PSD, EIRP and flags will vary. What if in future any new member or existing member also starts varying based on power mode ? If we follow the Approach B, then again, all those places we will need to introduce another If-else condition to check and then take values. > > I think you and Wen should go work together and figure out the story as you > think it should be - I don't have a lot of opinion on it, and thus I'm not sure it's > reasonable to ask me to figure out all the different things. > > Please work together and come up with a coherent story of how to handle > this, hopefully including multi-interface scenarios and maybe regulatory > database, internal data structures, etc. > Sure, we will sync up again and look for a different approach if at all its feasible. But so far as per our earlier internal discussions, the proposed way of handling separate ieee80211_channel seems to be more feasible. > Johannes Aditya
