Message ID | 20240328055235.3034174-2-quic_mdharane@quicinc.com (mailing list archive) |
---|---|
State | RFC |
Delegated to: | Johannes Berg |
Headers | show |
Series | Add Multi-Link Reconfigure link removal support | expand |
On Thu, 2024-03-28 at 11:22 +0530, Manish Dharanenthiran wrote: > > + * @ie: ML reconfigure IE to be updated in beacon in the link going to be > + * removed and in all affiliated links. > + * @ie_len: ML reconfigure IE length Given the spec having moved away from "Information Element" in favour of just "Element", I'd prefer to do the same in the code. Not that we really want to rename all the "ie" stuff in the code now, but for new code. > + * @link_reconfig_remove: Notifies the driver about the link to be > + * scheduled for removal with ML reconfigure IE built for that particular > + * link along with the TBTT count until which the beacon with ML > + * reconfigure IE should be sent. Same here. > +/** > + * cfg80211_update_link_reconfig_remove_status - Inform userspace about > + * the removal status of link which is scheduled for removal > + * @dev: the device on which the operation is requested > + * @link_id: Link which is undergoing removal > + * @tbtt_count: Current tbtt_count to be updated. > + * @tsf: Beacon's timestamp value > + * @status: Inform started or completed action to userspace based on the value > + * received, > + * i) 0 (IEEE80211_LINK_RECONFIG_START) - Send > + * NL80211_CMD_LINK_REMOVAL_STARTED > + * ii) 1 (IEEE80211_LINK_RECONFIG_COMPLETE) - Send > + * NL80211_CMD_LINK_REMOVAL_COMPLETED I wouldn't list the values "0" and "1"? They're really quite unimportant. Also we've sometimes used just the nl80211 cmd value as a parameter, could do that here too instead of adding IEEE80211_LINK_RECONFIG_START and IEEE80211_LINK_RECONFIG_COMPLETE? > + * This function is used to inform userspace about the ongoing link removal > + * status. 'IEEE80211_LINK_RECONFIG_START' is issued when the first beacon with > + * ML reconfigure IE is sent out. This event can be used by userspace to start > + * the BTM in case of AP mode. And, IEEE80211_LINK_RECONFIG_COMPLETE is issued > + * when the last beacon is sent with ML reconfigure IE. This is used to > + * initiate the deletion of that link, also to trigger deauth/disassoc for the > + * associated peer(s). I'm not fully sure I understand this - the way I read it, userspace actually request link removal with NL80211_CMD_REMOVE_LINK (at least right now, will comment separately), why does it need an event too? > + * Note: This API is currently used by drivers which supports offloaded > + * Multi-Link reconfigure link removal. Returns failure if FEATURE FLAG is not > + * set or success if NL message is sent. What would be "non-offloaded ML reconfiguration link removal"? What does offloaded even mean here? It's only counting down and then removing the link, no? Isn't that fundamentally an operation that has to happen in kernel or device space, since that's sending beacons? I don't see you'd really want to time the updates to each beacon from userspace? > +++ b/include/uapi/linux/nl80211.h > @@ -1304,6 +1304,10 @@ > * @NL80211_CMD_REMOVE_LINK: Remove a link from an interface. This may come > * without %NL80211_ATTR_MLO_LINK_ID as an easy way to remove all links > * in preparation for e.g. roaming to a regular (non-MLO) AP. > + * To initiate link removal procedure, set below attributes, > + * %NL80211_ATTR_AP_REMOVAL_COUNT - AP removal timer count(TBTT) > + * %NL80211_ATTR_IE - ML reconfigure Information element > + * Can be extended to update multiple TBTT & IE(s). I'm wondering if this really is the right API? For example, older kernels would ignore all the other attributes and immediately delete the link, is that what you want? Seems you might want to at least _know_ about the availability of (graceful) link removal. Also, if it should piggy-back on an existing API, maybe better would be STOP_AP? That's the operation that normally stops beaconing, although if you just delete the link the kernel does have to clean that up ... Or maybe it should just be a whole new operation? You're already adding new commands for the events anyway, could use _START (dropping the "ED") for both a command and an event. Though see above, not sure why you need the event anyway. So just not sure about this, any arguments either way? I guess if it were part of STOP_AP you'd expect the link to stay around and just be inactive, and then require it to be removed by userspace with NL80211_CMD_REMOVE_LINK after it stops, so perhaps in some way doing it via NL80211_CMD_REMOVE_LINK makes more sense so it will actually be removed entirely. > * @NL80211_CMD_ADD_LINK_STA: Add a link to an MLD station > * @NL80211_CMD_MODIFY_LINK_STA: Modify a link of an MLD station > @@ -1329,6 +1333,14 @@ > * %NL80211_ATTR_MLO_TTLM_ULINK attributes are used to specify the > * TID to Link mapping for downlink/uplink traffic. > * > + * @NL80211_CMD_LINK_REMOVAL_STARTED: Once first beacon with reconfiguration MLE > + * is sent, userspace is notified with the TBTT and TSF value to indicate > + * timestamp of that beacon using %NL80211_ATTR_AP_REMOVAL_COUNT and > + * %NL80211_ATTR_TSF respectively. > + * > + * @NL80211_CMD_LINK_REMOVAL_COMPLETED: Once last beacon with reconfiguration > + * MLE is sent, userspace is notified with completion. We already have NL80211_CMD_LINKS_REMOVED for the station side of this, maybe we should just reuse that event also here? > + * @NL80211_ATTR_AP_REMOVAL_COUNT: (u16) TBTT count up-to which reconfiguration > + * MLE is sent. Also, userspace will be notified with this count once the > + * first beacon with reconfiguration MLE is sent. I'm not sure how that notification thing all makes sense when it's something requested by userspace in the first place? Are you expecting the underlying driver to actually _change_ it? > + * @NL80211_ATTR_TSF: (u64) TSF value when the first beacon with reconfiguration > + * MLE is sent. Why is that needed? But also the name is very generic, which I don't mind, but perhaps then the documentation should reflect that this use is when it's used with that event etc. > + * @NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD: Driver/device which supports > + * ML reconfig link removal offload. Ah, I guess that addresses the whole "can the driver do it" part. Though like I said above I'm not sure why you call this offloaded, I'm not convinced you'd ever want to do it in a non-offloaded way? > + [NL80211_ATTR_TSF] = { .type = NLA_U64 }, Not sure that makes sense, it's not used for input? > struct wireless_dev *wdev = dev->ieee80211_ptr; > + struct cfg80211_link_reconfig_removal_params params = {}; > + bool is_ml_reconfig = false; > + int ret = 0; You can remove ret, just rewrite the code below a bit better. > +int > +cfg80211_update_link_reconfig_remove_status(struct net_device *netdev, > + unsigned int link_id, I feel like this should check the link_id against valid_links? > + u8 tbtt_count, u64 tsf, > + enum ieee80211_link_reconfig_remove_state action) > +{ > + struct wiphy *wiphy = netdev->ieee80211_ptr->wiphy; > + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); > + struct sk_buff *msg; > + void *hdr = NULL; > + int ret = 0; Please read https://staticthinking.wordpress.com/2024/02/28/return-0-is-better-than-return-ret/ I really do agree with him a lot here :-) So please don't init ret = 0, and "return 0" on the success path. > + /* Only for ML reconfigure link removal offloaded driver, need to > + * update the status about the ongoing link removal to userspace. > + */ > + if (!wiphy_ext_feature_isset(wiphy, > + NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD)) > + return -EOPNOTSUPP; > + > + trace_cfg80211_update_link_reconfig_remove_status(wiphy, netdev, > + link_id, tbtt_count, > + tsf, action); > + > + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); > + if (!msg) > + return -ENOMEM; > + > + if (action == IEEE80211_LINK_RECONFIG_START) > + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_LINK_REMOVAL_STARTED); > + else if (action == IEEE80211_LINK_RECONFIG_COMPLETE) > + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_LINK_REMOVAL_COMPLETED); You can save this if you actually just have the driver pass the command ID. However, seems like the function should update valid_links, just like cfg80211_links_removed() does? Or maybe it should just become valid to call cfg80211_links_removed() for AP interfaces in this context ... > + nla_put_u8(msg, NL80211_ATTR_AP_REMOVAL_COUNT, tbtt_count) || > + nla_put_u64_64bit(msg, NL80211_ATTR_TSF, tsf, > + NL80211_ATTR_PAD)) { Those don't make sense after removal completed, so they shouldn't be there. But again, perhaps that's just going to become cfg80211_links_removed() anyway. > + nla_put_failure: > + genlmsg_cancel(msg, hdr); The cancel is pointless if you just free the message, and then you don't need to initialize hdr=NULL either. > + nlmsg_free(msg); > > +TRACE_EVENT(rdev_link_reconfig_remove, > + TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, > + const struct cfg80211_link_reconfig_removal_params *params), > + > + TP_ARGS(wiphy, netdev, params), That's pretty inconsistent indentation, I'd prefer to do it like the other events, even if checkpatch complains a bit ... > + TP_STRUCT__entry(WIPHY_ENTRY > + NETDEV_ENTRY > + __field(u32, link_id) > + __field(u16, count) > + __dynamic_array(u8, frame, params->ie_len) > + ), > + > + TP_fast_assign(WIPHY_ASSIGN; > + NETDEV_ASSIGN; > + __entry->link_id = params->link_id; > + __entry->count = params->link_removal_cntdown; > + memcpy(__get_dynamic_array(frame), params->ie, > + params->ie_len); > + ), Same here, this might make checkpatch happier, but honestly, I much prefer the style that all the other events have ... > +int cfg80211_link_reconfig_remove(struct wireless_dev *wdev, > + const struct cfg80211_link_reconfig_removal_params *params) > +{ > + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy); > + int ret = -EINVAL; > + > + lockdep_assert_wiphy(wdev->wiphy); > + > + /* Currently, removal of link from MLD is supported for AP BSS only, it > + * can be extended for non-AP/STA MLD as well but that shall use > + * action frame to update about its link reconfiguration. > + */ > + if (wdev->iftype == NL80211_IFTYPE_AP) > + ret = rdev_link_reconfig_remove(rdev, wdev->netdev, params); > + > + return ret; Oh come on, you don't even need the 'ret' variable. johannes
On 3/27/2024 10:52 PM, Manish Dharanenthiran wrote: [...] > +/** > + * cfg80211_update_link_reconfig_remove_status - Inform userspace about > + * the removal status of link which is scheduled for removal > + * @dev: the device on which the operation is requested > + * @link_id: Link which is undergoing removal > + * @tbtt_count: Current tbtt_count to be updated. > + * @tsf: Beacon's timestamp value > + * @status: Inform started or completed action to userspace based on the value kernel-doc warns: include/net/cfg80211.h:9573: warning: Function parameter or struct member 'action' not described in 'cfg80211_update_link_reconfig_remove_status' include/net/cfg80211.h:9573: warning: Excess function parameter 'status' description in 'cfg80211_update_link_reconfig_remove_status' > + * received, > + * i) 0 (IEEE80211_LINK_RECONFIG_START) - Send > + * NL80211_CMD_LINK_REMOVAL_STARTED > + * ii) 1 (IEEE80211_LINK_RECONFIG_COMPLETE) - Send > + * NL80211_CMD_LINK_REMOVAL_COMPLETED > + * > + * > + * This function is used to inform userspace about the ongoing link removal > + * status. 'IEEE80211_LINK_RECONFIG_START' is issued when the first beacon with > + * ML reconfigure IE is sent out. This event can be used by userspace to start > + * the BTM in case of AP mode. And, IEEE80211_LINK_RECONFIG_COMPLETE is issued > + * when the last beacon is sent with ML reconfigure IE. This is used to > + * initiate the deletion of that link, also to trigger deauth/disassoc for the > + * associated peer(s). > + * > + * Note: This API is currently used by drivers which supports offloaded > + * Multi-Link reconfigure link removal. Returns failure if FEATURE FLAG is not > + * set or success if NL message is sent. > + */ > +int > +cfg80211_update_link_reconfig_remove_status(struct net_device *dev, > + unsigned int link_id, > + u8 tbtt_count, u64 tsf, > + enum ieee80211_link_reconfig_remove_state action); > + > #endif /* __NET_CFG80211_H */ [...] /jeff
On 3/28/2024 11:48 PM, Johannes Berg wrote: > On Thu, 2024-03-28 at 11:22 +0530, Manish Dharanenthiran wrote: >> >> + * @ie: ML reconfigure IE to be updated in beacon in the link going to be >> + * removed and in all affiliated links. >> + * @ie_len: ML reconfigure IE length > > Given the spec having moved away from "Information Element" in favour of > just "Element", I'd prefer to do the same in the code. Not that we > really want to rename all the "ie" stuff in the code now, but for new > code. > >> + * @link_reconfig_remove: Notifies the driver about the link to be >> + * scheduled for removal with ML reconfigure IE built for that particular >> + * link along with the TBTT count until which the beacon with ML >> + * reconfigure IE should be sent. > > Same here. > Sure, will address in all the places >> +/** >> + * cfg80211_update_link_reconfig_remove_status - Inform userspace about >> + * the removal status of link which is scheduled for removal >> + * @dev: the device on which the operation is requested >> + * @link_id: Link which is undergoing removal >> + * @tbtt_count: Current tbtt_count to be updated. >> + * @tsf: Beacon's timestamp value >> + * @status: Inform started or completed action to userspace based on the value >> + * received, >> + * i) 0 (IEEE80211_LINK_RECONFIG_START) - Send >> + * NL80211_CMD_LINK_REMOVAL_STARTED >> + * ii) 1 (IEEE80211_LINK_RECONFIG_COMPLETE) - Send >> + * NL80211_CMD_LINK_REMOVAL_COMPLETED > > I wouldn't list the values "0" and "1"? They're really quite > unimportant. > > Also we've sometimes used just the nl80211 cmd value as a parameter, > could do that here too instead of adding IEEE80211_LINK_RECONFIG_START > and IEEE80211_LINK_RECONFIG_COMPLETE? > I thought to add these in the description so that the action taken in these API is more clear, but it worked in other way. Will address this in next version. >> + * This function is used to inform userspace about the ongoing link removal >> + * status. 'IEEE80211_LINK_RECONFIG_START' is issued when the first beacon with >> + * ML reconfigure IE is sent out. This event can be used by userspace to start >> + * the BTM in case of AP mode. And, IEEE80211_LINK_RECONFIG_COMPLETE is issued >> + * when the last beacon is sent with ML reconfigure IE. This is used to >> + * initiate the deletion of that link, also to trigger deauth/disassoc for the >> + * associated peer(s). > > I'm not fully sure I understand this - the way I read it, userspace > actually request link removal with NL80211_CMD_REMOVE_LINK (at least > right now, will comment separately), why does it need an event too? > >> + * Note: This API is currently used by drivers which supports offloaded >> + * Multi-Link reconfigure link removal. Returns failure if FEATURE FLAG is not >> + * set or success if NL message is sent. > > What would be "non-offloaded ML reconfiguration link removal"? What does > offloaded even mean here? It's only counting down and then removing the > link, no? Isn't that fundamentally an operation that has to happen in > kernel or device space, since that's sending beacons? I don't see you'd > really want to time the updates to each beacon from userspace? > By offloaded, we tried to convey that the synchronization of the reconfiguration IE(TBTT count) between partner links is taken care by the firmware instead of hostap/kernel. Yeah as you mentioned it is actually counting down and then removing but the thing here is, since the synchronization is done on the firmware side, this event is used to send the timestamp value of the first beacon sent with reconfiguration element and as well as the current the TBTT count. This timestamp of the first beacon is needed to start the BTM request/disassoc timer along with the value received from the driver. >> +++ b/include/uapi/linux/nl80211.h >> @@ -1304,6 +1304,10 @@ >> * @NL80211_CMD_REMOVE_LINK: Remove a link from an interface. This may come >> * without %NL80211_ATTR_MLO_LINK_ID as an easy way to remove all links >> * in preparation for e.g. roaming to a regular (non-MLO) AP. >> + * To initiate link removal procedure, set below attributes, >> + * %NL80211_ATTR_AP_REMOVAL_COUNT - AP removal timer count(TBTT) >> + * %NL80211_ATTR_IE - ML reconfigure Information element >> + * Can be extended to update multiple TBTT & IE(s). > > I'm wondering if this really is the right API? For example, older > kernels would ignore all the other attributes and immediately delete the > link, is that what you want? Seems you might want to at least _know_ > about the availability of (graceful) link removal. > > Also, if it should piggy-back on an existing API, maybe better would be > STOP_AP? That's the operation that normally stops beaconing, although if > you just delete the link the kernel does have to clean that up ... > > Or maybe it should just be a whole new operation? You're already adding > new commands for the events anyway, could use _START (dropping the "ED") > for both a command and an event. Though see above, not sure why you need > the event anyway. > > So just not sure about this, any arguments either way? I guess if it > were part of STOP_AP you'd expect the link to stay around and just be > inactive, and then require it to be removed by userspace with > NL80211_CMD_REMOVE_LINK after it stops, so perhaps in some way doing it > via NL80211_CMD_REMOVE_LINK makes more sense so it will actually be > removed entirely. With the new reconfiguration procedure, we are not stopping the beacon or putting the BSS to inactive or such, we still continue to operate and serve the peers connected to the AP MLD, rather we are trying to intimate that this link is going to removed 'after this' many count just like CSA. Station associated to this might take action based on its capabilities or just ignore this element. That's the reason we went with piggy-backing the existing remove link API but instead of removing immediately we just by-passing when TBTT & IE attributes are present. > >> * @NL80211_CMD_ADD_LINK_STA: Add a link to an MLD station >> * @NL80211_CMD_MODIFY_LINK_STA: Modify a link of an MLD station >> @@ -1329,6 +1333,14 @@ >> * %NL80211_ATTR_MLO_TTLM_ULINK attributes are used to specify the >> * TID to Link mapping for downlink/uplink traffic. >> * >> + * @NL80211_CMD_LINK_REMOVAL_STARTED: Once first beacon with reconfiguration MLE >> + * is sent, userspace is notified with the TBTT and TSF value to indicate >> + * timestamp of that beacon using %NL80211_ATTR_AP_REMOVAL_COUNT and >> + * %NL80211_ATTR_TSF respectively. >> + * >> + * @NL80211_CMD_LINK_REMOVAL_COMPLETED: Once last beacon with reconfiguration >> + * MLE is sent, userspace is notified with completion. > > We already have NL80211_CMD_LINKS_REMOVED for the station side of this, > maybe we should just reuse that event also here? > This has other functionality as well similar to "cfg80211_remove_link", can I add case similar to how I extended the "NL80211_CMD_REMOVE_LINK" handler? >> + * @NL80211_ATTR_AP_REMOVAL_COUNT: (u16) TBTT count up-to which reconfiguration >> + * MLE is sent. Also, userspace will be notified with this count once the >> + * first beacon with reconfiguration MLE is sent. > > I'm not sure how that notification thing all makes sense when it's > something requested by userspace in the first place? Are you expecting > the underlying driver to actually _change_ it? > >> + * @NL80211_ATTR_TSF: (u64) TSF value when the first beacon with reconfiguration >> + * MLE is sent. > > Why is that needed? But also the name is very generic, which I don't > mind, but perhaps then the documentation should reflect that this use is > when it's used with that event etc. > Sure, will update the documentation. >> + * @NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD: Driver/device which supports >> + * ML reconfig link removal offload. > > Ah, I guess that addresses the whole "can the driver do it" part. > > Though like I said above I'm not sure why you call this offloaded, I'm > not convinced you'd ever want to do it in a non-offloaded way? > >> + [NL80211_ATTR_TSF] = { .type = NLA_U64 }, > > Not sure that makes sense, it's not used for input? > We are using this attribute to notify the timestamp to userspace, so thought adding a policy would be good. >> struct wireless_dev *wdev = dev->ieee80211_ptr; >> + struct cfg80211_link_reconfig_removal_params params = {}; >> + bool is_ml_reconfig = false; >> + int ret = 0; > > You can remove ret, just rewrite the code below a bit better. > >> +int >> +cfg80211_update_link_reconfig_remove_status(struct net_device *netdev, >> + unsigned int link_id, > > I feel like this should check the link_id against valid_links? > >> + u8 tbtt_count, u64 tsf, >> + enum ieee80211_link_reconfig_remove_state action) >> +{ >> + struct wiphy *wiphy = netdev->ieee80211_ptr->wiphy; >> + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); >> + struct sk_buff *msg; >> + void *hdr = NULL; >> + int ret = 0; > > Please read > https://staticthinking.wordpress.com/2024/02/28/return-0-is-better-than-return-ret/ > > I really do agree with him a lot here :-) > > So please don't init ret = 0, and "return 0" on the success path. > Thanks for sharing this! Will address all the return variable discrepancy here and in other places as well. >> + /* Only for ML reconfigure link removal offloaded driver, need to >> + * update the status about the ongoing link removal to userspace. >> + */ >> + if (!wiphy_ext_feature_isset(wiphy, >> + NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD)) >> + return -EOPNOTSUPP; >> + >> + trace_cfg80211_update_link_reconfig_remove_status(wiphy, netdev, >> + link_id, tbtt_count, >> + tsf, action); >> + >> + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); >> + if (!msg) >> + return -ENOMEM; >> + >> + if (action == IEEE80211_LINK_RECONFIG_START) >> + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_LINK_REMOVAL_STARTED); >> + else if (action == IEEE80211_LINK_RECONFIG_COMPLETE) >> + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_LINK_REMOVAL_COMPLETED); > > You can save this if you actually just have the driver pass the command > ID. However, seems like the function should update valid_links, just > like cfg80211_links_removed() does? Or maybe it should just become valid > to call cfg80211_links_removed() for AP interfaces in this context ... > we are not yet deleting the link as such though we say completed. Complete here meant only for what the userspace has initiated. Its up to the userspace to decide on what would be the next step. Like, it may send broadcast BM, flush out all the peers connected and then remove the link completely. Hence, didn't do any changes on the valid_links part. > >> + nla_put_u8(msg, NL80211_ATTR_AP_REMOVAL_COUNT, tbtt_count) || >> + nla_put_u64_64bit(msg, NL80211_ATTR_TSF, tsf, >> + NL80211_ATTR_PAD)) { > > Those don't make sense after removal completed, so they shouldn't be > there. But again, perhaps that's just going to become > cfg80211_links_removed() anyway. > >> + nla_put_failure: >> + genlmsg_cancel(msg, hdr); > > The cancel is pointless if you just free the message, and then you don't > need to initialize hdr=NULL either. > Since i had hdr allocation inside if else if block and then have check for NULL pointer, it made sense to initialize to NULL. But with changes to send the command id, I will update this code in the next version. >> + nlmsg_free(msg); >> >> +TRACE_EVENT(rdev_link_reconfig_remove, >> + TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, >> + const struct cfg80211_link_reconfig_removal_params *params), >> + >> + TP_ARGS(wiphy, netdev, params), > > That's pretty inconsistent indentation, I'd prefer to do it like the > other events, even if checkpatch complains a bit ... > checkpatch had complained this and I though the expectation here is to have similar indentation as well. Will update the trace.h in this and in the next 2/2 patch as well. >> + TP_STRUCT__entry(WIPHY_ENTRY >> + NETDEV_ENTRY >> + __field(u32, link_id) >> + __field(u16, count) >> + __dynamic_array(u8, frame, params->ie_len) >> + ), >> + >> + TP_fast_assign(WIPHY_ASSIGN; >> + NETDEV_ASSIGN; >> + __entry->link_id = params->link_id; >> + __entry->count = params->link_removal_cntdown; >> + memcpy(__get_dynamic_array(frame), params->ie, >> + params->ie_len); >> + ), > > Same here, this might make checkpatch happier, but honestly, I much > prefer the style that all the other events have ... > >> +int cfg80211_link_reconfig_remove(struct wireless_dev *wdev, >> + const struct cfg80211_link_reconfig_removal_params *params) >> +{ >> + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy); >> + int ret = -EINVAL; >> + >> + lockdep_assert_wiphy(wdev->wiphy); >> + >> + /* Currently, removal of link from MLD is supported for AP BSS only, it >> + * can be extended for non-AP/STA MLD as well but that shall use >> + * action frame to update about its link reconfiguration. >> + */ >> + if (wdev->iftype == NL80211_IFTYPE_AP) >> + ret = rdev_link_reconfig_remove(rdev, wdev->netdev, params); >> + >> + return ret; > > Oh come on, you don't even need the 'ret' variable. > > johannes Sure :) will address all the ret variable at once in the next version.
On 3/29/2024 2:32 AM, Jeff Johnson wrote: > On 3/27/2024 10:52 PM, Manish Dharanenthiran wrote: > [...] >> +/** >> + * cfg80211_update_link_reconfig_remove_status - Inform userspace about >> + * the removal status of link which is scheduled for removal >> + * @dev: the device on which the operation is requested >> + * @link_id: Link which is undergoing removal >> + * @tbtt_count: Current tbtt_count to be updated. >> + * @tsf: Beacon's timestamp value >> + * @status: Inform started or completed action to userspace based on the value > > kernel-doc warns: > > include/net/cfg80211.h:9573: warning: Function parameter or struct member 'action' not described in 'cfg80211_update_link_reconfig_remove_status' > include/net/cfg80211.h:9573: warning: Excess function parameter 'status' description in 'cfg80211_update_link_reconfig_remove_status' > > /jeff Will address that in the upcoming version. Is there any way to run this locally similar to checkpatch? so that we will make sure check this as well before sending to community in upcoming patches. Regards Manish Dharanenthiran
On 3/29/2024 10:16 AM, Manish Dharanenthiran wrote: > On 3/29/2024 2:32 AM, Jeff Johnson wrote: >> kernel-doc warns: >> >> include/net/cfg80211.h:9573: warning: Function parameter or struct member 'action' not described in 'cfg80211_update_link_reconfig_remove_status' >> include/net/cfg80211.h:9573: warning: Excess function parameter 'status' description in 'cfg80211_update_link_reconfig_remove_status' [...] > Is there any way to run this locally similar to checkpatch? so that we > will make sure check this as well before sending to community in > upcoming patches. I use: files=$(git diff --name-only $base HEAD) scripts/kernel-doc -Wall -Werror -none $files
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 2e2be4fd2bb6..b6914f107b87 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -4169,6 +4169,23 @@ struct mgmt_frame_regs { u32 global_mcast_stypes, interface_mcast_stypes; }; +/** + * struct cfg80211_link_reconfig_removal_params - Contains params needed for + * link reconfig removal + * @link_removal_cntdown: TBTT countdown value until which the beacon with ML + * reconfigure IE will be sent. + * @ie: ML reconfigure IE to be updated in beacon in the link going to be + * removed and in all affiliated links. + * @ie_len: ML reconfigure IE length + * @link_id: Link id of the link to be removed. + */ +struct cfg80211_link_reconfig_removal_params { + u16 link_removal_cntdown; + const u8 *ie; + size_t ie_len; + unsigned int link_id; +}; + /** * struct cfg80211_ops - backend description for wireless configuration * @@ -4570,6 +4587,11 @@ struct mgmt_frame_regs { * * @set_hw_timestamp: Enable/disable HW timestamping of TM/FTM frames. * @set_ttlm: set the TID to link mapping. + * + * @link_reconfig_remove: Notifies the driver about the link to be + * scheduled for removal with ML reconfigure IE built for that particular + * link along with the TBTT count until which the beacon with ML + * reconfigure IE should be sent. */ struct cfg80211_ops { int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow); @@ -4931,6 +4953,9 @@ struct cfg80211_ops { struct cfg80211_set_hw_timestamp *hwts); int (*set_ttlm)(struct wiphy *wiphy, struct net_device *dev, struct cfg80211_ttlm_params *params); + int (*link_reconfig_remove)(struct wiphy *wiphy, + struct net_device *dev, + const struct cfg80211_link_reconfig_removal_params *params); }; /* @@ -9509,4 +9534,42 @@ ssize_t wiphy_locked_debugfs_write(struct wiphy *wiphy, struct file *file, void *data); #endif +enum ieee80211_link_reconfig_remove_state { + IEEE80211_LINK_RECONFIG_START, + IEEE80211_LINK_RECONFIG_COMPLETE, +}; + +/** + * cfg80211_update_link_reconfig_remove_status - Inform userspace about + * the removal status of link which is scheduled for removal + * @dev: the device on which the operation is requested + * @link_id: Link which is undergoing removal + * @tbtt_count: Current tbtt_count to be updated. + * @tsf: Beacon's timestamp value + * @status: Inform started or completed action to userspace based on the value + * received, + * i) 0 (IEEE80211_LINK_RECONFIG_START) - Send + * NL80211_CMD_LINK_REMOVAL_STARTED + * ii) 1 (IEEE80211_LINK_RECONFIG_COMPLETE) - Send + * NL80211_CMD_LINK_REMOVAL_COMPLETED + * + * + * This function is used to inform userspace about the ongoing link removal + * status. 'IEEE80211_LINK_RECONFIG_START' is issued when the first beacon with + * ML reconfigure IE is sent out. This event can be used by userspace to start + * the BTM in case of AP mode. And, IEEE80211_LINK_RECONFIG_COMPLETE is issued + * when the last beacon is sent with ML reconfigure IE. This is used to + * initiate the deletion of that link, also to trigger deauth/disassoc for the + * associated peer(s). + * + * Note: This API is currently used by drivers which supports offloaded + * Multi-Link reconfigure link removal. Returns failure if FEATURE FLAG is not + * set or success if NL message is sent. + */ +int +cfg80211_update_link_reconfig_remove_status(struct net_device *dev, + unsigned int link_id, + u8 tbtt_count, u64 tsf, + enum ieee80211_link_reconfig_remove_state action); + #endif /* __NET_CFG80211_H */ diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index f917bc6c9b6f..bfc6080816b8 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -1304,6 +1304,10 @@ * @NL80211_CMD_REMOVE_LINK: Remove a link from an interface. This may come * without %NL80211_ATTR_MLO_LINK_ID as an easy way to remove all links * in preparation for e.g. roaming to a regular (non-MLO) AP. + * To initiate link removal procedure, set below attributes, + * %NL80211_ATTR_AP_REMOVAL_COUNT - AP removal timer count(TBTT) + * %NL80211_ATTR_IE - ML reconfigure Information element + * Can be extended to update multiple TBTT & IE(s). * * @NL80211_CMD_ADD_LINK_STA: Add a link to an MLD station * @NL80211_CMD_MODIFY_LINK_STA: Modify a link of an MLD station @@ -1329,6 +1333,14 @@ * %NL80211_ATTR_MLO_TTLM_ULINK attributes are used to specify the * TID to Link mapping for downlink/uplink traffic. * + * @NL80211_CMD_LINK_REMOVAL_STARTED: Once first beacon with reconfiguration MLE + * is sent, userspace is notified with the TBTT and TSF value to indicate + * timestamp of that beacon using %NL80211_ATTR_AP_REMOVAL_COUNT and + * %NL80211_ATTR_TSF respectively. + * + * @NL80211_CMD_LINK_REMOVAL_COMPLETED: Once last beacon with reconfiguration + * MLE is sent, userspace is notified with completion. + * * @NL80211_CMD_MAX: highest used command number * @__NL80211_CMD_AFTER_LAST: internal use */ @@ -1586,6 +1598,10 @@ enum nl80211_commands { NL80211_CMD_SET_TID_TO_LINK_MAPPING, + NL80211_CMD_LINK_REMOVAL_STARTED, + + NL80211_CMD_LINK_REMOVAL_COMPLETED, + /* add new commands above here */ /* used to define NL80211_CMD_MAX below */ @@ -2856,6 +2872,13 @@ enum nl80211_commands { * %NL80211_CMD_ASSOCIATE indicating the SPP A-MSDUs * are used on this connection * + * @NL80211_ATTR_AP_REMOVAL_COUNT: (u16) TBTT count up-to which reconfiguration + * MLE is sent. Also, userspace will be notified with this count once the + * first beacon with reconfiguration MLE is sent. + * + * @NL80211_ATTR_TSF: (u64) TSF value when the first beacon with reconfiguration + * MLE is sent. + * * @NUM_NL80211_ATTR: total number of nl80211_attrs available * @NL80211_ATTR_MAX: highest attribute number currently defined * @__NL80211_ATTR_AFTER_LAST: internal use @@ -3401,6 +3424,9 @@ enum nl80211_attrs { NL80211_ATTR_ASSOC_SPP_AMSDU, + NL80211_ATTR_AP_REMOVAL_COUNT, + NL80211_ATTR_TSF, + /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, @@ -6545,6 +6571,9 @@ enum nl80211_feature_flags { * (signaling and payload protected) A-MSDUs and this shall be advertised * in the RSNXE. * + * @NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD: Driver/device which supports + * ML reconfig link removal offload. + * * @NUM_NL80211_EXT_FEATURES: number of extended features. * @MAX_NL80211_EXT_FEATURES: highest extended feature index. */ @@ -6620,6 +6649,7 @@ enum nl80211_ext_feature_index { NL80211_EXT_FEATURE_OWE_OFFLOAD_AP, NL80211_EXT_FEATURE_DFS_CONCURRENT, NL80211_EXT_FEATURE_SPP_AMSDU_SUPPORT, + NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD, /* add new features before the definition below */ NUM_NL80211_EXT_FEATURES, diff --git a/net/wireless/core.h b/net/wireless/core.h index 118f2f619828..ce1a1aa048e2 100644 --- a/net/wireless/core.h +++ b/net/wireless/core.h @@ -552,6 +552,8 @@ void cfg80211_remove_links(struct wireless_dev *wdev); int cfg80211_remove_virtual_intf(struct cfg80211_registered_device *rdev, struct wireless_dev *wdev); void cfg80211_wdev_release_link_bsses(struct wireless_dev *wdev, u16 link_mask); +int cfg80211_link_reconfig_remove(struct wireless_dev *wdev, + const struct cfg80211_link_reconfig_removal_params *params); /** * struct cfg80211_colocated_ap - colocated AP information diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index b4edba6b0b7b..252d019c4d45 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -826,6 +826,8 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = { [NL80211_ATTR_MLO_TTLM_DLINK] = NLA_POLICY_EXACT_LEN(sizeof(u16) * 8), [NL80211_ATTR_MLO_TTLM_ULINK] = NLA_POLICY_EXACT_LEN(sizeof(u16) * 8), [NL80211_ATTR_ASSOC_SPP_AMSDU] = { .type = NLA_FLAG }, + [NL80211_ATTR_AP_REMOVAL_COUNT] = { .type = NLA_U8 }, + [NL80211_ATTR_TSF] = { .type = NLA_U64 }, }; /* policy for the key attributes */ @@ -16103,6 +16105,9 @@ static int nl80211_remove_link(struct sk_buff *skb, struct genl_info *info) unsigned int link_id = nl80211_link_id(info->attrs); struct net_device *dev = info->user_ptr[1]; struct wireless_dev *wdev = dev->ieee80211_ptr; + struct cfg80211_link_reconfig_removal_params params = {}; + bool is_ml_reconfig = false; + int ret = 0; /* cannot remove if there's no link */ if (!info->attrs[NL80211_ATTR_MLO_LINK_ID]) @@ -16115,9 +16120,35 @@ static int nl80211_remove_link(struct sk_buff *skb, struct genl_info *info) return -EINVAL; } - cfg80211_remove_link(wdev, link_id); + if (info->attrs[NL80211_ATTR_AP_REMOVAL_COUNT]) { + /* Parsing and sending information to driver about ML + * reconfiguration is supported only when + * NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD is set + */ + if (!wiphy_ext_feature_isset(wdev->wiphy, + NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD)) + return -EOPNOTSUPP; - return 0; + /* If AP removal count is present, it is mandatory to have IE + * attribute as well, return error if not present + */ + if (!info->attrs[NL80211_ATTR_IE]) + return -EINVAL; + + is_ml_reconfig = true; + params.ie = nla_data(info->attrs[NL80211_ATTR_IE]); + params.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]); + params.link_removal_cntdown = + nla_get_u16(info->attrs[NL80211_ATTR_AP_REMOVAL_COUNT]); + params.link_id = link_id; + } + + if (is_ml_reconfig) + ret = cfg80211_link_reconfig_remove(wdev, ¶ms); + else + cfg80211_remove_link(wdev, link_id); + + return ret; } static int @@ -20214,6 +20245,72 @@ void cfg80211_schedule_channels_check(struct wireless_dev *wdev) } EXPORT_SYMBOL(cfg80211_schedule_channels_check); +int +cfg80211_update_link_reconfig_remove_status(struct net_device *netdev, + unsigned int link_id, + u8 tbtt_count, u64 tsf, + enum ieee80211_link_reconfig_remove_state action) +{ + struct wiphy *wiphy = netdev->ieee80211_ptr->wiphy; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + struct sk_buff *msg; + void *hdr = NULL; + int ret = 0; + + /* Only for ML reconfigure link removal offloaded driver, need to + * update the status about the ongoing link removal to userspace. + */ + if (!wiphy_ext_feature_isset(wiphy, + NL80211_EXT_FEATURE_MLD_LINK_REMOVAL_OFFLOAD)) + return -EOPNOTSUPP; + + trace_cfg80211_update_link_reconfig_remove_status(wiphy, netdev, + link_id, tbtt_count, + tsf, action); + + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + if (!msg) + return -ENOMEM; + + if (action == IEEE80211_LINK_RECONFIG_START) + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_LINK_REMOVAL_STARTED); + else if (action == IEEE80211_LINK_RECONFIG_COMPLETE) + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_LINK_REMOVAL_COMPLETED); + + if (!hdr) { + ret = -ENOBUFS; + goto nla_put_failure; + } + + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) || + nla_put_u32(msg, NL80211_ATTR_IFINDEX, netdev->ifindex)) { + ret = -EINVAL; + goto nla_put_failure; + } + + if (nla_put_u8(msg, NL80211_ATTR_MLO_LINK_ID, link_id) || + nla_put_u8(msg, NL80211_ATTR_AP_REMOVAL_COUNT, tbtt_count) || + nla_put_u64_64bit(msg, NL80211_ATTR_TSF, tsf, + NL80211_ATTR_PAD)) { + ret = -EINVAL; + goto nla_put_failure; + } + + genlmsg_end(msg, hdr); + + genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0, + NL80211_MCGRP_MLME, GFP_ATOMIC); + + return ret; + + nla_put_failure: + genlmsg_cancel(msg, hdr); + nlmsg_free(msg); + + return ret; +} +EXPORT_SYMBOL(cfg80211_update_link_reconfig_remove_status); + /* initialisation/exit functions */ int __init nl80211_init(void) diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h index 43897a5269b6..cbf5da73fbb0 100644 --- a/net/wireless/rdev-ops.h +++ b/net/wireless/rdev-ops.h @@ -1459,6 +1459,23 @@ rdev_del_intf_link(struct cfg80211_registered_device *rdev, trace_rdev_return_void(&rdev->wiphy); } +static inline int +rdev_link_reconfig_remove(struct cfg80211_registered_device *rdev, + struct net_device *dev, + const struct cfg80211_link_reconfig_removal_params *params) +{ + int ret = -EOPNOTSUPP; + + trace_rdev_link_reconfig_remove(&rdev->wiphy, dev, params); + + if (rdev->ops->link_reconfig_remove) + ret = rdev->ops->link_reconfig_remove(&rdev->wiphy, dev, + params); + + trace_rdev_return_int(&rdev->wiphy, ret); + return ret; +} + static inline int rdev_add_link_station(struct cfg80211_registered_device *rdev, struct net_device *dev, diff --git a/net/wireless/trace.h b/net/wireless/trace.h index e039e66ab377..ac174afd768b 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -4005,6 +4005,62 @@ TRACE_EVENT(rdev_set_ttlm, WIPHY_PR_ARG, NETDEV_PR_ARG) ); +TRACE_EVENT(rdev_link_reconfig_remove, + TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, + const struct cfg80211_link_reconfig_removal_params *params), + + TP_ARGS(wiphy, netdev, params), + + TP_STRUCT__entry(WIPHY_ENTRY + NETDEV_ENTRY + __field(u32, link_id) + __field(u16, count) + __dynamic_array(u8, frame, params->ie_len) + ), + + TP_fast_assign(WIPHY_ASSIGN; + NETDEV_ASSIGN; + __entry->link_id = params->link_id; + __entry->count = params->link_removal_cntdown; + memcpy(__get_dynamic_array(frame), params->ie, + params->ie_len); + ), + + TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", link_id: %u frame:0x%.2x count:%d", + WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->link_id, + le16_to_cpup((__le16 *)__get_dynamic_array(frame)), + __entry->count) +); + +TRACE_EVENT(cfg80211_update_link_reconfig_remove_status, + TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, + unsigned int link_id, u8 tbtt_count, u64 tsf, + enum ieee80211_link_reconfig_remove_state action), + + TP_ARGS(wiphy, netdev, link_id, tbtt_count, tsf, action), + + TP_STRUCT__entry(WIPHY_ENTRY + NETDEV_ENTRY + __field(u32, link_id) + __field(u8, tbtt_count) + __field(u64, tsf) + __field(enum ieee80211_link_reconfig_remove_state, action) + ), + + TP_fast_assign(WIPHY_ASSIGN; + NETDEV_ASSIGN; + __entry->link_id = link_id; + __entry->tbtt_count = tbtt_count; + __entry->tsf = tsf; + __entry->action = action; + ), + + TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", link_id: %u tbtt:%u tsf: %lld, action: %d", + WIPHY_PR_ARG, NETDEV_PR_ARG, + __entry->link_id, __entry->tbtt_count, + __entry->tsf, __entry->action) +); + #endif /* !__RDEV_OPS_TRACE || TRACE_HEADER_MULTI_READ */ #undef TRACE_INCLUDE_PATH diff --git a/net/wireless/util.c b/net/wireless/util.c index 2bde8a354631..69f09390257d 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -2799,6 +2799,24 @@ bool cfg80211_iftype_allowed(struct wiphy *wiphy, enum nl80211_iftype iftype, } EXPORT_SYMBOL(cfg80211_iftype_allowed); +int cfg80211_link_reconfig_remove(struct wireless_dev *wdev, + const struct cfg80211_link_reconfig_removal_params *params) +{ + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy); + int ret = -EINVAL; + + lockdep_assert_wiphy(wdev->wiphy); + + /* Currently, removal of link from MLD is supported for AP BSS only, it + * can be extended for non-AP/STA MLD as well but that shall use + * action frame to update about its link reconfiguration. + */ + if (wdev->iftype == NL80211_IFTYPE_AP) + ret = rdev_link_reconfig_remove(rdev, wdev->netdev, params); + + return ret; +} + void cfg80211_remove_link(struct wireless_dev *wdev, unsigned int link_id) { struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);