Ben, sorry for the delay, I was too busy thinking about other stuff.
On Thu, 2011-11-10 at 11:25 -0800, Ben Greear wrote:
> But, I don't think it is going to work..or at least if it can, I
> don't see a good way to do it.
>
> I'm stuck in the ieee80211_ht_cap_ie_to_sta_ht_cap method. With
> my original patch, I apply overrides here, at the bottom of the
> method. If we're associated (or started associating)
> and user asked for over-rides, we'll apply requested overrides, else
> nothing will change because the over-rides mask is not set.
>
> But, if I have to use pre-computed values here then I need to
> be certain they are set properly. If association has been
> requested, then that is fine. But, what about the
> sta_apply_parameters() method? Can we guarantee that association has
> been requested when this method is called? I think we cannot,
> and if not, then I cannot use pre-computed sdata->used_ht_caps.
> I could attempt to set a flag when used_ht_caps
> has been calculated, and add a check for that, but that is yet another piece
> of computed state that could be stale if we make a mistake somewhere.
We can't, but can't we like assign sdata->ht_caps = sband->ht_caps? Or
maybe even calculate restricted HT caps for both 2.4 and 5 GHz?
Basically what I was thinking is this:
struct sub_if_data {
...
struct ieee80211_sta_ht_cap ht_cap[num_bands];
...
};
We'd use *that* everywhere, and when associating we calculate
sdata->ht_cap[band] = apply_overrides(sbands[band]->ht_cap);
and when disassociating we simply
memcpy(sdata->ht_cap[band], sbands[band]->ht_cap, ...);
or so? Then we can always use sdata->ht_cap[bands] instead of
sband->ht_caps everywhere, and overrides are implicit.
Was this what you attempted?
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
