On Wed, Jul 28, 2010 at 3:05 PM, Felix Fietkau <nbd@xxxxxxxxxxx> 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. Sound good, so based on the passed info, will cfg80211 lift off STBC capability settings if 1 stream 1x1 settings are used? 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
