[PATCH 10/27] wifi: mac80211: isolate driver from inactive links

[Wen Gong]

On 6/15/2023 3:56 PM, Johannes Berg wrote:
> On Thu, 2023-06-15 at 10:26 +0800, Wen Gong wrote:
>> On 6/15/2023 2:32 AM, Johannes Berg wrote:
>>> On Wed, 2023-05-24 at 15:41 +0800, Wen Gong wrote:
>>>> May I add a new ops in struct ieee80211_ops? like this:
>>>>
>>>> u16 active_links(struct ieee80211_hw *hw, struct ieee80211_vif vif, u16
>>>> new_links)"
>>>>
>>>> then ieee80211_set_vif_links_bitmaps() call the ops to get the links for
>>>> station and set the sdata->vif.active_links with the return value from
>>>> lower driver,
>>>> it means lower driver will dynamic select the links count at this moment.
>>>>
>>>> If lower driver not register ops active_links, then keep current logic.
>>>>
>>> I guess you can can send patches for whatever you want :)
>>>
>>> But I have no idea what you're trying to do? Why would you need to have
>>> a callback?
>> Currently driver could use ieee80211_set_active_links_async() to active
>> links after connection completed.
> Right.
>
>> But I would like to allow driver to select active links in a early time,
>> it will be more convenient for driver.
> How so? All you have to do is look for the connection becoming
> authorized (e.g. sta state for the AP moving to authorized) and then
> selecting the links you want. We've already been working on that, it's
> really easy?
It is more complex for ath12k drivers.
>
> On the flip-side, it would be highly inconvenient for mac80211 to try to
> enable more links *during* the association process, and actually it's
> not even allowed by spec until the 4-way-HS finishes. So the earliest
> possible time is pretty much when you can just do it in the driver as I
> just described.
>
>>> Was this for link selection in the driver? We should have a patch
>>> somewhere that adds a BSS_CHANGE flag for when the valid links change,
>>> so the driver can select others.
>>>
>>> johannes
>> Yes, it is for link selection in driver at a early time before
>> connection completed.
> This is not really allowed ... At least not without also finding ways to
> really transmit the 802.1X and 4-way-HS only on the right link, etc.
Yes, I also found this in section "2.7.6.1 General"  of IEEE P802.11be:
"For MLO, if RSNA has not been established, each message of the 4-way 
handshake shall be sent on
the same link used by the latest exchange of successful (Re)Association 
Request/Response frames."

For ath12k drivers, only the primary link(the link used by the latest 
exchange of successful (Re)Association
Request/Response frames) is active before key installed, so the 802.1X 
and 4-way-HS will always sent on
the primary link, so it will meet the rule above of section "2.7.6.1 
General".

It means: lower driver will ensure the rule when it implmented the 
active_links callback such as ath12k.
>> Could you tell detail about how the BSS_CHANGE flag works?😁
> The work isn't complete yet, but basically it just calls the callback
> whenever the valid_links changed, say by link-reconfiguration.
>
> johannes