________________________________________ From: Arend van Spriel [arend@xxxxxxxxxxxx] Sent: Friday, June 22, 2012 12:32 AM To: Johannes Berg Cc: Mahesh Palivela; linville@xxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx Subject: Re: [RFC v3] cfg80211/mac80211: 802.11ac changes 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 [MP] Should I declare another constant for this? +#define IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895 0 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 -- 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
