On Wed, 2012-09-26 at 22:52 +0530, Mahesh Palivela wrote: > On 9/26/2012 5:23 PM, Johannes Berg wrote: > >> you mean to say some drivers which dont provide its own VHT caps, will > >> use remote STA VHT caps as its own? > >> If so I feel not correct posing remote STA caps as local caps. > > > > No, no. If you look at HT, then you'll see that if the driver has HT but > > isn't capable of doing everything the peer STA can do, then mac80211 > > restricts tells the driver > > Sorry. Where is it telling the driver? I couldn't find this part of code > in mac80211, could you point me? Well struct ieee80211_sta is what the driver uses. That's where it's "telling" the driver, by making the data accessible to the driver. Your new vht_cap field there is also "telling the driver" that way. > > I agree that this isn't really necessary and can be rather complex in > > VHT, but I think you need to document the difference very clearly in the > > documentation for the ieee80211_sta VHT caps. > > Can this go as different patch? take my v2 patch as framework. More > implementation of vht.c at later point of time? I don't think this makes sense, since we're talking only about a documentation change to your patch. See: * @ht_cap: HT capabilities of this STA; restricted to our own TX capabilities + * @vht_cap: VHT capabilities of this STA The difference is that you don't say "restricted to own", but I think you should explicitly say that it isn't restricted. johannes -- 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
