Re: [PATCH v8 2/2] mac80211: Support ht-cap over-rides.

[Ben Greear <greearb@candelatech.com>]

On 11/17/2011 03:28 AM, Johannes Berg wrote:
> 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];
> 	...
> };

So we'd have to copy this data from sbands[] upon creation
of the interface to make sure it is always initialized?
This would allow us to easily support the overrides for
non-station interfaces, so I do like that benefit.

Can the sbands[] data ever change for any reason once
an interface is created?  If not, then probably this is
doable.  If it can change, then we are screwed.

> 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?

I was trying to use a single calculated-ht-cap struct instead
of one for each band, and I was trying to put it into sdata->u.sta,
which made initialization issues much more scary for me.

It seems you are basically wanting to copy the sband[] data
local to each interface (sdata), and then we would remove sband from most
(or all?) of the method calls that deal with sband->ht_caps?

Looks like quite a bit of code churn, and probably requiring at least two
patches:
  * Get rid of sband usage by copying the sband data into sdata
  * Add the over-ride logic


Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com