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.
