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

[Ben Greear <greearb@candelatech.com>]

On 11/17/2011 09:25 AM, Johannes Berg wrote:
> On Thu, 2011-11-17 at 09:22 -0800, Ben Greear wrote:
>
>>> 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.
>
> I don't think it can change but it's not const (I think?) so drivers
> might do stupid things -- but that would be buggy anyway.

I can imagine someone wanting to poke at a driver to enable/disable
features, but no idea if it is done yet.

>> 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?
>
> I guess. Though we still need the band to know which one to use (I'm
> reluctant to say we just need one due to channel switching etc.)
>
>> 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
>
> Yeah. It might be *too much* churn, but that's what I was thinking. If
> you think it's likely too much churn let's go with what you have now,
> there are only a few minor things about it I don't like much.

I would much rather use something similar to my last-posted patch.  I
think it is a lot less risky than rewriting all of the sband usage.

I'll rebase against the latest wireless-testing and post a patch
for further review, hopefully later today.

Thanks,
Ben

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