On Tue, 2012-09-25 at 15:19 +0530, Mahesh Palivela wrote: > > OTOH, this would only matter to drivers that actually support all these > > features, and those drivers could take care of not enabling the features > > if their hardware doesn't support them. However, think of a driver that > > is for different hardware, some that supports beamforming and some that > > doesn't. Then if we mask out the beamforming capability of a station if > > it's not locally supported, that driver could be simpler? Then again, if > > we don't the driver just has to check if the hardware supports it, which > > seems reasonable as well. > > > > Do you understand the issue? > > > > why should we mask out remote STA caps bits. Our local hw caps are in > sband->sta.vht_caps. remote caps sta_info->sta.vht_caps. In what way > drivers are connected with remote STA vht caps bits. Well imagine you have a driver for some hardware that can do beamforming, and the same driver can also work with hardware that doesn't. If we restrict remote caps, like we do for HT, the driver doesn't have to worry about this but can just do whatever the remote caps say is possible. If we don't restrict it, the driver has to also check its own caps. We can do this, and I suspect it will be simpler, but it needs to be *very clearly* documented since VHT will then be different from HT. 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
