Re: [PATCH wireless-next v2 12/31] wifi: mm81x: add mac.c

[Lachlan Hodges]

On Thu, Jun 04, 2026 at 01:46:32PM +0200, Johannes Berg wrote:
> 
> > +static void mm81x_mac_ops_flush(struct ieee80211_hw *hw,
> > +				struct ieee80211_vif *vif, u32 queues,
> > +				bool drop)
> > +{
> > +	struct mm81x *mors = hw->priv;
> > +
> > +	/* We don't support IEEE80211_HW_QUEUE_CONTROL so flush all queues */
> > +	if (drop) {
> > +		/*
> > +		 * No need to call mm81x_skbq_stop_tx_queues as mac80211
> > +		 * has already cancelled each queue prior to calling .flush()
> > +		 */
> > +		mm81x_skbq_data_traffic_pause(mors);
> > +
> > +		flush_work(&mors->hif_work);
> > +		flush_work(&mors->tx_stale_work);
> > +
> > +		mm81x_hif_clear_events(mors);
> > +		mm81x_hif_flush_tx_data(mors);
> > +		mm81x_hif_flush_cmds(mors);
> > +
> > +		/* Reenable data, not that there will be any */
> > +		mm81x_skbq_data_traffic_resume(mors);
> > +	}
> > +}
> 
> Doing nothing in the !drop case seems questionable - mac80211 uses this
> sometimes to e.g. make sure a deauth frame really went out before
> shutting down the hardware.

Yea I agree, we should handle both cases it looks like need to
rework some of the hw queue logic such that we can handle the !drop
case.

> > +static void mm81x_mac_ops_sta_rc_update(struct ieee80211_hw *hw,
> > +					struct ieee80211_vif *vif,
> > +					struct ieee80211_link_sta *link_sta,
> > +					u32 changed)
> > +{
> > +	struct mm81x *mors = hw->priv;
> > +	struct ieee80211_sta *sta = link_sta->sta;
> > +	enum ieee80211_sta_state old_state;
> > +	enum ieee80211_sta_state new_state;
> > +
> > +	dev_dbg(mors->dev,
> > +		"Rate control config updated (changed %u, peer address %pM)",
> > +		changed, sta->addr);
> > +
> > +	if (!(changed & IEEE80211_RC_BW_CHANGED))
> > +		return;
> > +
> > +	/*
> > +	 * Simulate the disconnection and connection to reinitialize the sta
> > +	 * in mmrc with new BW
> > +	 */
> > +	old_state = IEEE80211_STA_ASSOC;
> > +	new_state = IEEE80211_STA_NOTEXIST;
> 
> No real objection since it's driver internal, but note that this
> transition is normally impossible from mac80211 since it doesn't go
> through the intermediate states.

I realised not too long ago that this function can be entirely removed
since this path is not possible in the current S1G implementation,
atleast until channel switching is implemented but compared to
regular wifi I don't think it's as important to have. So I'm just
going to remove it for v3.

lachlan