From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [wireless-next PATCH 3/5] wifi: Allow overriding some HT information.
Date: Fri, 28 Oct 2011 09:33:34 -0700 [thread overview]
Message-ID: <4EAAD95E.1030001@candelatech.com> (raw)
In-Reply-To: <1319789573.3914.15.camel@jlt3.sipsolutions.net>
On 10/28/2011 01:12 AM, Johannes Berg wrote:
> On Thu, 2011-10-27 at 22:11 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> * Allow configuring the mcs (/n) rates available.
>> * Allow configuration of MAX-A-MSDU
>> * Allow configuration of A-MPDU factor& density.
>>
>> Users can only remove existing rates. The MSDU and MPDU
>> values can be set to any value allowed by the 802.11n
>> specification.
>
> That can't work -- the device might not support it.
The device would always support removing rates, right?
As for the MSDU and MPDU stuff, I would need to add capabilities
flags and then enable each driver as they are tested?
> I also don't really like the way you pass in some binary "mask" when
> it's not really a binary masking operation.
I found the mask to work very well. It's easy enough to
deal with in user-space, and easily allows us to add override features
(the additional bits to support the MPDU stuff once the
HT rates logic was in is a very small bit of code).
Otherwise, I'll need to add new netlink commands for each new
feature. That is going to bloat hostapd as well as the
kernel.
>
>> struct vif_params {
>> int use_4addr;
>> int disable_11n;
>> int disable_ht40;
>> + struct ieee80211_ht_cap *ht_capa;
>> + struct ieee80211_ht_cap *ht_capa_mask;
>
> Same comments as before again -- this is per connection right?
I meant it to be per interface. I'm using lots of virtual stations,
and want some to act like /abg radios, and others to be ht-20 only,
and others to be capable of only up to mcs7, etc.
>> @@ -114,6 +115,19 @@ static void ieee80211_add_ht_ie(struct sk_buff *skb, const u8 *ht_info_ie,
>> if (ht_info_ie[1]< sizeof(struct ieee80211_ht_info))
>> return;
>>
>> + memcpy(&ht_cap,&sband->ht_cap, sizeof(ht_cap));
>> + /*
>> + * This is for an association attempt, and we must
>> + * advert at least the first 8 rates, even if we
>> + * will later force the rate control to a lower rate.
>> + */
>> + ieee80211_apply_htcap_overrides(sdata,&ht_cap, 8);
>
> Yuck, why, why hard-code 8, etc.
I can make a define that involves MCS7.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2011-10-28 16:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 5:11 [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n greearb
2011-10-28 5:11 ` [wireless-next PATCH 2/5] wifi: Support disabling ht40 greearb
2011-10-28 8:09 ` Johannes Berg
2011-10-28 16:25 ` Ben Greear
2011-10-28 5:11 ` [wireless-next PATCH 3/5] wifi: Allow overriding some HT information greearb
2011-10-28 8:12 ` Johannes Berg
2011-10-28 16:33 ` Ben Greear [this message]
2011-11-02 8:13 ` Johannes Berg
2011-11-02 16:59 ` Ben Greear
2011-11-02 17:49 ` Johannes Berg
2011-11-02 18:03 ` Ben Greear
2011-11-03 8:32 ` Johannes Berg
2011-10-28 5:11 ` [wireless-next PATCH 4/5] wifi: Warn if cannot add station debugfs entries greearb
2011-10-28 8:13 ` Johannes Berg
2011-10-28 16:13 ` Ben Greear
2011-10-28 5:11 ` [wireless-next PATCH 5/5] wifi-debugfs: Fix AMSDU rate printout greearb
2011-10-28 8:13 ` Johannes Berg
2011-11-17 17:49 ` Ben Greear
2011-11-17 18:03 ` John W. Linville
2011-10-28 5:15 ` [wireless-next PATCH 1/5] mac80211: Support forcing station to disable 11n Ben Greear
2011-10-28 8:08 ` Johannes Berg
2011-10-28 16:24 ` Ben Greear
2011-11-02 7:56 ` Johannes Berg
2011-11-02 16:37 ` Ben Greear
2011-10-28 18:55 ` Ben Greear
2011-11-02 7:53 ` Johannes Berg
2011-11-02 16:34 ` Ben Greear
2011-11-02 17:51 ` Johannes Berg
2011-11-03 6:04 ` Ben Greear
2011-11-03 8:30 ` Johannes Berg
2011-11-03 18:17 ` Ben Greear
2011-11-04 14:42 ` Johannes Berg
2011-11-04 16:11 ` Ben Greear
2011-11-04 16:17 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EAAD95E.1030001@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.