Re: [RFC v3] cfg80211/mac80211: 802.11ac changes

["Arend van Spriel" <arend@broadcom.com>]

On 06/21/2012 08:39 PM, Johannes Berg wrote:
> On Thu, 2012-06-21 at 20:34 +0200, Arend van Spriel wrote:
>> On 06/21/2012 08:14 PM, Johannes Berg wrote:
>>> On Thu, 2012-06-21 at 16:51 +0000, Mahesh Palivela wrote:
>>>
>>>> +/* 802.11ac VHT Capabilities */
>>>> +#define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991                0x00000001
>>>> +#define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454               0x00000002
>>>
>>> I have a feeling there should be a value for 3895, since this isn't
>>> really a bitfield only (it doesn't make sense to set both of these, in
>>> fact 3 is reserved)
>>
>> These are matching the values specified for the VHP Capability Info IE.
>> 3895 is specified as 0. Value 3 is reserved because it is not to be
>> regarded as a bit field.
> 
> Right, but I think it'd make more sense to actually have the 3895 value
> as a constant here so you're not tempted to think that you could set

Understood. I though you were suggesting

+/* 802.11ac VHT Capabilities */
+#define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895   1
+#define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991   2
+#define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454  3

for internal use. I agree adding 0 value for 3895 clarifies that it is
not a bitfield.

> both bits? anyway ... I hope whoever adds VHT to their driver knows what
> they're doing so it doesn't matter much :)

I hope so too :-p

> johannes
> 
> 


Gr. AvS