On 8/21/2024 2:28 PM, Johannes Berg wrote:
On Wed, 2024-08-07 at 09:15 +0530, Manish Dharanenthiran wrote:
+/* Defines for ML Reconfigure removal offload */
Not really "defines", but whatever? Is there value in this comment
anyway though? Don't see how it adds much.
Will modify accordingly in upcoming version.
+/**
+ * ieee80211_update_link_reconfig_remove_update - Inform userspace about
+ * the removal status of link which is scheduled for removal
+ * @vif: interface in which reconfig removal status is received.
+ * @link_id: Link which is undergoing removal
+ * @tbtt_count: Current tbtt_count to be updated.
+ * @tsf: Beacon's timestamp value
+ * @cmd: Inform started or completed action to userspace
+ *
+ * For description, check cfg80211_link_reconfig_remove_update
+ */
+int ieee80211_update_link_reconfig_remove_update(struct ieee80211_vif *vif,
+ unsigned int link_id,
+ u32 tbtt_count, u64 tsf,
+ enum nl80211_commands cmd);
And anyway this is a trivial wrapper, why not make it so the cfg80211
API takes the wdev, and then just call it directly in the driver with
ieee80211_vif_to_wdev(), or have a trivial inline? No reason to have the
iftype check in mac80211 either, that can be in cfg80211 and/or drivers?
Sure, will address this in upcoming version.
Other than that it looks OK I guess, but I do wonder if you've actually
tested further than that?
Yes, have tested this along with the driver changes. But, as you
mentioned it needs further more changes to make this work in real time.
Will update all the changes in next version as a patch series.
It seems to me that ieee80211_del_link_station() is somewhat broken when
you remove the deflink from the STA, since we'll continue using data
from there?
Yes, link sta delete has to be handled where we would move the deflink
sta to next valid link, if its available.
johannes
Thanks Johannes for the review. Will incorporate the comments given in
this RFC, also add the other necessary changes which are tested and
update them as patch series.
Regards
Manish Dharanenthiran
