Received-SPF: pass (google.com: domain of linux-wireless+bounces-3859-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <beee9cc5-6174-473b-bd57-1101430f200b@quicinc.com>
Date: Wed, 21 Feb 2024 18:22:11 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel switch
 on link basis
Content-Language: en-US
To: Johannes Berg <johannes@sipsolutions.net>,
        Ping-Ke Shih
	<pkshih@realtek.com>
CC: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        "Jeff
 Johnson" <quic_jjohnson@quicinc.com>,
        Ilan Peer <ilan.peer@intel.com>, "Jouni
 Malinen" <j@w1.fi>,
        Ryder Lee <ryder.lee@mediatek.com>,
        Arend van Spriel
	<arend.vanspriel@broadcom.com>,
        Felix Fietkau <nbd@openwrt.org>
References: <20240130140918.1172387-1-quic_adisi@quicinc.com>
 <20240130140918.1172387-5-quic_adisi@quicinc.com>
 <b73dd1f9c23c164179c38e2109aa1550d87e87ed.camel@sipsolutions.net>
 <646d1e3e404a437f4c99c80996eb4f194ac242b8.camel@sipsolutions.net>
 <26df9aa6-e497-4040-ad5c-c647454acca6@quicinc.com>
 <b2cf5c1d-7842-4e59-b25a-904a6879fa9c@quicinc.com>
 <f7174207668cac149246cafa0e4b4749ee3289f0.camel@sipsolutions.net>
 <ac5825e8-0cb1-476e-be5c-ad0170122f77@quicinc.com>
 <fe2100dcfe9ae9b4517f239faf25374c27f473a5.camel@sipsolutions.net>
 <5c0fd2eb-eb19-4b69-a325-ad9eef633336@quicinc.com>
 <bc81466177afd0014ccdd9030c5807339bb288db.camel@sipsolutions.net>
 <18c0d4de-392a-420c-8a05-466a83cd2eb8@quicinc.com>
 <3c550ae335a9762a9cbd0c8109b6dd99faeb8f6f.camel@sipsolutions.net>
 <5a89e63fb7644d12be72154c90c96199@realtek.com>
 <32b5e358f7b54f4921e0a9e44a71f3a791f0d0da.camel@sipsolutions.net>
From: Aditya Kumar Singh <quic_adisi@quicinc.com>
In-Reply-To: <32b5e358f7b54f4921e0a9e44a71f3a791f0d0da.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

On 2/21/24 13:39, Johannes Berg wrote:
> Qualcomm:
>   - copies and updates CSA/ECSA elements all by itself
>   - btw, not sure here about probe responses, does it do that too?

We had a thought about keeping this CSA/ECSA handling at host/kernel 
level only. But the major point of concern is _synchronization_ among 
firmware of each of the links participating in the MLD.

* Even if we ignore TSF/TBTT synchronization for a moment, how firmware 
will know when to transmit the beacon with a particular counter or when 
CSA has finished on other link? If rely on host's update then there is 
room for further delay and hence errors.
      - This is because, counter value on the reported link depends on 
the last beacon transmitted by the affected link.

* Host can send the template on all links but how to ensure that first 
template is reached on the affected link and then only on the partner 
links? Host will queue the command properly but reaping of the command 
on n (no of links) independent firmware can not be guaranteed in the 
same order in which host has filled. It depends how busy each of host to 
firmware path is.

* And then obviously, considering TSF/TBTT will be again complicating 
the synchronization part and making it more difficult to manage just via 
host.

Hence there is a strong urge to let firmware handle all this for beacons.

As far as how firmware will _magically_ communicate among themselves is 
concerned, we have *IPC* in place to achieve that. One link firmware can 
talk to other link firmware when required.


				Kernel Level
____________________________________________________________________________
  -------------- 	      -------------- 		 --------------
|   Firmware 1 |  <- IPC ->  |   Firmware 2 | <- IPC -> |   Firmware 3 |
|    on HW 1   |	     |    on HW 2   |           |    on HW 3   |
  -------------- 	      --------------             --------------


Hence, host just needs to update template of the affected link and 
indicate to firmware that it is a critical update. This firmware then 
can indicate other link firmware(s) to append CSA/ECSA IE with a given 
counter value to its beacon via this IPC. Parsing the IE and 
de-fragmenting and fragmenting it again can be done by firmware itself. 
(Agree that it is bit complex but when comparing with complexity of 
maintaining synchronicity across links, this looks more doable)

Hence we have taken "offloading beacons fully to firmware" approach.

For probe responses, it is handled in host/kernel only. Firmware sends 
back the last transmitted count in beacon to host. So we have the last 
transmitted count info. Per STA profile generation logic is also there. 
So we manage via that.