On Fri, 2012-02-24 at 08:40 -0800, Javier Cardona wrote: > Hi Johannes, > > On Thu, Feb 23, 2012 at 11:19 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Thu, 2012-02-23 at 18:30 -0800, Ashok Nagarajan wrote: > > > >> +/* > >> + * NOTE: Mesh peer links are established only if average rssi of the peer > >> + * candidate satisfies the threshold. sta_meets_rssi_treshold doesn't use > >> + * hysteresis as fluctuations around threshold have no adverse effects. > >> + */ > >> + > >> +#define sta_meets_rssi_threshold(sta, sdata) \ > >> + (sdata->vif.bss_conf.cqm_rssi_thold == 0 || \ > >> + ((s8) -ewma_read(&sta->avg_signal)) > \ > >> + sdata->vif.bss_conf.cqm_rssi_thold) > > > > This also isn't right, you're using a value (bss_conf.cqm_rssi_thold) > > intended for *signalling* for actual *decision making*. > > Isn't that value used for making the decision (in userspace) on > whether a signal is good enough to associate? I don't think so, and if it happens to be the same value, that's still not encoded in the API -- this value is really meant to be only for the signalling in the API. > On an open mesh this > decision takes place in the kernel. It made more sense to us to reuse > that parameter for mesh than to introduce a new one. Would you rather > see a separate mesh parameter for this? Yes, I think that makes more sense. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
