[ath9k-devel] [RFC] ath9k_htc: Add support for NL80211_IFTYPE_MESH_POINT interfaces

[Pavel Roskin <proski@gnu.org>]

Hello!

You may want to copy to linux-wireless as well.  You'll get more 
eyeballs looking at your code.

On 06/06/2011 08:55 PM, Javier Cardona wrote:
> More specifically, enable AP-style beaconing on mesh ifaces, honor
> FIF_OTHER_BSS filter and change the hw capabilities to reflect mesh
> support.
>
> Tested on two TP-Link TL-WN821N and with this patch we could establish peer
> links and ping.
...
> +	case NL80211_IFTYPE_MESH_POINT:
> +		/* 802.11s defines a different beaconing method for mesh points
> +		 * that closely resembles AP-style beaconing.  Until that is
> +		 * implemented, just use AP-style beaconing for mesh points. */
> +		/* Fall through */
>   	case NL80211_IFTYPE_AP:
>   		ath9k_htc_beacon_config_ap(priv, cur_conf);

Is it fundamentally impossible for AP and mesh VIFs to coexist?  If it's 
possible, you may want to use NL80211_IFTYPE_AP even if there is a mesh 
VIF and use num_ap_vif and num_mbss_vif to code needed for AP and mesh 
respectively.

Having distinct global opmodes would stand in the way if AP and mesh 
coexistence is to be implemented.

By the way, we may want to use distinctive names for the common opmodes 
to avoid confusion with the VIF modes.

> +	if (priv->num_mbss_vif ||
> +	    (priv->nvifs&&  vif->type == NL80211_IFTYPE_MESH_POINT)) {
> +		ath_err(common, "Mesh BSS coexistence with other modes is not allowed\n");
> +		mutex_unlock(&priv->mutex);
> +		return -ENOBUFS;
> +	}

This code appears to allow only one mesh interface.  Is that your 
intention?  I think you just copied the code from Ad-Hoc without 
realizing what it does.

> +	if (priv->rxfilter&  FIF_OTHER_BSS)
> +		rfilt |= ATH9K_RX_FILTER_MCAST_BCAST_ALL;

I think this could be a separate patch.  It may have effect beyond mesh 
support.

-- 
Regards,
Pavel Roskin