Rameshkumar Sundaram <quic_ramess@xxxxxxxxxxx> writes: > From: Sriram R <quic_srirrama@xxxxxxxxxxx> > > To prepare the driver for MLO support, split the driver vif > data structure to scale for multiple links. This requires changing > the use of arvif to per link and not per hw which can now > comprise of multiple links. > Also since most configurations from mac80211 are done per link, do refactoring > of the driver functions to apply these configurations at link level. > > Split ath12k_vif which is the driver private of ieee80211_vif to store > link specific information as ath12k_link_vif. For default use cases > the ath12k vif will have a preallocated link vif called deflink which will > be used by non ML and the first link vif of ML vif. > > With MLO Support to be added, remaining link vifs will be allocated during > channel assignment where vdev create/start happens. These link vifs will be > freed during interface down. > > Current ath12k_vif(arvif) structure > > +---------------+ +---------------+ +---------------+ > | ieee80211_vif | | ieee80211_vif | | ieee80211_vif | > | private data | | private data | | private data | > | | | | | | > | ath12k_vif | | ath12k_vif | | ath12k_vif | > | (arvif) | | (arvif) | | (arvif) | > | | | | | | > | +----------+ | | +----------+ | | +----------+ | > | |*ar (2GHz)| | | |*ar (5GHz)| | | |*ar (2GHz)| | > | +----------+ | | +----------+ | | +----------+ | > | | | | | | > +---------------+ +---------------+ +---------------+ > > Proposed ath12k_vif(ahvif) containing ath12k_link_vif(s) (arvif) > (deflink is preallocated member which is always the first link if > ieee80211_vif is MLD and is the only link otherwise) > > +---------------------------------+ > | ieee80211_vif | > | private data | > | | > | ath12k_vif(ahvif) | > | | > | +-------------------------------+ > | |ath12k_link_vif deflink (arvif)| > | | +---------------+ | > | | | *ar(2GHz) | | > | +-------------------------------+ > | +-------------------------------+ > | | ath12k_link_vif *link (arvif)| > | | +---------------+ | > | | | *ar(5GHz) | | > | +-------------------------------+ > | +-------------------------------+ > | | ath12k_link_vif *link (arvif)| > | | +---------------+ | > | | | *ar(6GHz) | | > | +-------------------------------+ > | | > +---------------------------------+ > > To refactor existing ath12k_vif to make use of link vifs, following > changes are made, > > 1. ath12k_vif now called by variable name ahvif stores multiple > arvifs(ah12k_link_vif) and also has a back pointer to ieee80211_vif. > > 2. In this patch set, only deflink is used to be on par with the > existing code. When MLO support is added the link id will be used to > fetch the arvif. > > 3. For mac80211 ops which doesn't use specific link_id, the config or info > is common for the vif, hence apply the config to all link vifs. > The links_map in the ahvif, will be used to identify all the link vifs that > are setup. > > 4. Change ath12k_vif_to_arvif() as ath12k_vif_to_ahvif() to fetch the > hw level vif. The link vif can be fetched from ahvif->link[], or the > deflink can be accessed via ahvif->deflink. API to access link > vif(arvif) by passing link_id can be introduced with MLO Support. > > 5. The ieee80211_vif can be accessed from ahvif using ath12k_ahvif_to_vif() > > Locking: > Currently modifications to members of arvif and arsta are protected by ar->conf_mutex > and it stays as such. > Now with these hw level structure (ahvif) being introduced, any modifications > to its members and link objects (i.e., arvifs[] which are dynamically allocated) > needs to be protected for writing and ah->conf_mutex is used for the same. > Also, atomic contexts(say WMI events and certain mac_ops) that we currently have in driver > will not(shouldn't be allowed) do any modifications but can read them and > rcu_read_lock() is used for the same. Please elaborate more about your locking design. Because of past bad contributions from Qualcomm the bar is really high for adding any new locks. I'm doing the locking analysis right now but it would help a lot if you could provide your own analysis. My first impressions: It's really confusing to have two locks with the same name (conf_mutex in struct ath12k_hw and struct ath12k). struct ath12k_hw already has hw_mutex so I'm even more suspicious about this locking design. That's not explained at all in commit messages. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
