Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/08/2011 01:02 PM, Johannes Berg wrote:

For example here:

   		if (!(ap_ht_cap_flags&   IEEE80211_HT_CAP_40MHZ_INTOLERANT)&&
+		    !ieee80111_cfg_override_disables_ht40(sdata)&&
   		(sband->ht_cap.cap&   IEEE80211_HT_CAP_SUP_WIDTH_20_40)&&
   		(hti->ht_param&   IEEE80211_HT_PARAM_CHAN_WIDTH_ANY)) {
   			switch(hti->ht_param&   IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {

This just adds complexity. If you calculate sdata->used_ht_caps first
then you can replace the sband->ht_cap.cap check with an
sdata->used_ht_caps.cap check and be done with it, instead of having to
check both.

I think that's a bad idea, but will change it if you insist.

I really think that'd be much nicer. As it is now we have to add all
these checks everywhere, if we just calculate it once and then change
places to use it we just have to remember to use the right thing.

I rebased against today's wireless-testing tree and started work on this.

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.

There is another caller in mesh_plink.c: mesh_plink_alloc()
I don't know much of anything about mesh, but I think we will always be
associated here.  The callers in mlme.c should always be associated as
far as I can tell.

The ieee80211_add_ht_ie method appears to be called when association is
already started, so it should be ok to use a derived value (it is
called only from send_assoc()).

If you prefer the additional-flag-if-already-calculated approach,
let me know and I'll continue on this path.  Or, if I'm confused
about the sta_apply_parameters path and it *is* always set?

Thanks,
Ben

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

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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux