From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.atheros.com ([12.36.123.2]:17076 "EHLO mail.atheros.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750952Ab0G2ALB (ORCPT ); Wed, 28 Jul 2010 20:11:01 -0400 Received: from mail.atheros.com ([10.10.20.108]) by sidewinder.atheros.com for ; Wed, 28 Jul 2010 17:11:01 -0700 Date: Wed, 28 Jul 2010 17:10:59 -0700 From: "Luis R. Rodriguez" To: Felix Fietkau CC: Luis Rodriguez , Bruno Randolf , "johannes@sipsolutions.net" , "linville@tuxdriver.com" , "linux-wireless@vger.kernel.org" Subject: Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration Message-ID: <20100729001059.GA2421@tux> References: <20100727094732.27186.30900.stgit@tt-desk> <4C4F0BB1.6030002@openwrt.org> <201007281106.06813.br1@einfach.org> <4C506DF7.9020907@openwrt.org> <4C50A08B.2080002@openwrt.org> <20100728213939.GB8033@tux> <4C50A9B9.5070708@openwrt.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4C50A9B9.5070708@openwrt.org> Sender: linux-wireless-owner@vger.kernel.org List-ID: 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