On Wed, Jul 28, 2010 at 03:05:45PM -0700, Felix Fietkau wrote: > On 2010-07-28 11:39 PM, Luis R. Rodriguez wrote: > > On Wed, Jul 28, 2010 at 02:26:35PM -0700, Felix Fietkau wrote: > >> We don't need any special case handling for this at all. Drivers already > >> calculate their HT capabilities based on the number of available chains. > >> Once the antenna selection stuff is actually used, they will have some > >> internal information about which chains have how many antennas. > >> > >> The reason why we can ignore *all* of this stuff for the API is simple: > >> We only need to refactor the code to calculate these settings based on > >> effective chainmask / antenna mask instead of pure hardware capability. > >> > >> The effective chainmask / antenna mask is basically the same as the > >> hardware settings, except that it gets masked with the values that are > >> configured through this API. That leaves us with something that's easy > >> to configure, easy to implement for drivers, and doesn't need special > >> case stuff for various 802.11n features. > > > > Consider the case of an already associated STA in 3x3 mode, and someone > > uses this API to limit it to a 1 stream 1x1 chaimask setting using > > only one antenna. How would the AP find out about this RX setting > > from the STA? Are we going to deny mucking with this prior to association? > > What about if you're the AP? > > > > If you are using STBC and the user tunes the device to 1 stream 1x1 chainmask > > settings, who deals with the required adaptations? > I think we should simply not accept runtime modifications of this stuff. > The user should bring down the interface, change the value, then bring > it back up again. That allows the driver to recalculate all the HT stuff > based on the updated chainmask/antenna mask without special cases. Works with me. Would we keep two values for some of these settings, an "actual hw" capablity and then also a "configured" values? Would this be exposed and visible through iw? Luis -- 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
