* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-21 20:28 UTC (permalink / raw)
To: Felix Fietkau
Cc: Bruno Randolf, David Quan, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com,
Luis Rodriguez, Sam Ng
In-Reply-To: <4BF6DAAE.6090903@openwrt.org>
On Fri, May 21, 2010 at 12:10 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-05-21 7:11 PM, Luis R. Rodriguez wrote:
>> On Thu, May 20, 2010 at 06:59:33PM -0700, Bruno Randolf wrote:
>>> so from my point of view this is not very different from what we can support
>>> with the API i suggested. for RX it seems to be 100% equivalent.
>>
>> Well I agree, the API *supports it* but I want *clean, clear and consistant
>> API*. And it just seems cleaner to separate the two.
>>
>>> the main difference as i see it is that with 802.11n you transmit on more than
>>> one antenna, while with 'legacy' we can only transmit on one antenna at a
>>> time.
>>
>> True, but note how the fact that you transmit over two antennas actually
>> has regulatory implications. Now, ath9k handles this within ath9k_hw already
>> but this itself seems like a worthy reason for this API to be separated.
>> While I think it is great for ath9k_hw to do this, wouldn't it be nice
>> if we can eventually instead expose the gain by using different chains
>> at the same time and do the regulatory calculation for all devices within
>> cfg80211?
>>
>>> actually i have to admit that on legacy "antenna set tx 3 (b11)" (select two
>>> antennas for transmit) does not make much sense. i have defined it before as
>>> "use diversity" but what about a different definition: like "bitmap of
>>> antennas/chains to TRANSMIT".
>>
>> Right, and while that *works*, I think it would be clearer to just use a
>> clear "diveristy" knob.
> Splitting it by mode of operation (11n vs legacy) does not work, because
> in AP mode you're doing both at the same time and there is an overlap in
> both settings.
Ah, hm, good point.
> I think that Bruno's suggestion of keeping them as one setting makes
> sense. About the regulatory concerns: where in the code does the
> chainmask currently affect the regulatory constraints?
I'm not sure, this was based on a quick review with David, I'll have
to review and poke at it but IIRC this was related to the chainmask
gains and I think we may get that from the EEPROM.
>>> so for 802.11n that would allow you to select multiple trasmit chains.
>>
>> Instead of leaving the API to be interpreted by the mode of operation
>> I think it would be much cleaner to just make your desires clearer and
>> have the API define it well, and let the driver reject/accept it.
>>
>>> on legacy you are only allowed to select one antenna
>>> in the bitmap. if it is set to "0" (or a separate flag) this could enable
>>> "follow RX antenna diversity" on legacy.
>>
>> Sure that is one way, but it seems cleaner and easier for legacy purposes
>> to just define an API that only fits legacy.
>>
>>> most of the other things you mention (need a reset/reassociate, regulatory
>>> concerns...) are driver implementation issues, which can be dealt with in the
>>> driver.
>>
>> Well so some of these things *could* be handled in mac80211 as well. For
>> example, we may want to just dissociate upon a tx/rx chain setting change
>> for all devices, but not for legacy. The regulatory stuff is another thing
>> which could eventually be made more generic accross the board.
>>
>> Additionally, suppose you write an iw-tweak-gui thingy, and you want to
>> provide expose tx/rx chainmask settings. Since some cards do not support
>> some chainmask settings we may want to allow for a query of unsupported
>> chainmasks and that way the GUI application could just grey-out the
>> unsupported chainmask settings instead of letting the user figure out
>> by trial and error that they are indeed not supported.
> The API should just provide a bitmask of possible chains/antennas to
> user space, which will be used as a mask for any values that the user
> space sets. That's easy for a GUI utility to process
The bitmask of possible chains/antennas makes more sense, we could
just add it to the general phy info request, it would just be a matter
of piggy backing a new attribute back.
Luis
^ permalink raw reply
* Re: How to scan APs with ATH5k?
From: Jaroslav Fojtik @ 2010-05-21 20:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Bob Copeland
In-Reply-To: <20100520224609.GA27842@hash.localnet>
Dear Bob,
> > It looks like a bug. Even if something is preventing scanning, the
> > error code should be -EBUSY (device busy).
> >
> > The same is true for ath9k, but I cannot test ath5k at the moment.
> > mac80211 does a considerable effort to allow scanning while associated.
>
> It's certainly something that used to work, but I haven't tried in
> a recent kernel. So yes probably a bug.
BTW: I do not have recent kernel. I am using:
linux-2.6.32.11 together with compat-wireless-2.6.34-rc4
Anyway, wlan1 returns different error when associated:
#root@dvouramenna:~# iwlist wlan1 scanning
#wlan1 Failed to read scan data : Resource temporarily unavailable
regards
J.Fojtik
> --
> Bob Copeland %% www.bobcopeland.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] iwlwifi fixes for 2.6.34
From: reinette chatre @ 2010-05-21 19:16 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <20100521182325.GA2495@tuxdriver.com>
Hi John,
On Fri, 2010-05-21 at 11:23 -0700, John W. Linville wrote:
> On Thu, May 13, 2010 at 02:49:43PM -0700, Reinette Chatre wrote:
> > We include two late fixes hoping to make it into 2.6.34.
> >
> > "iwlwifi: fix internal scan race" fixes a kernel crash caused by
> > accessing a NULL pointer. More can be read in
> > https://bugzilla.kernel.org/show_bug.cgi?id=15824
> >
> > "iwlagn: work around rate scaling reset delay" is already in
> > wireless-next-2.6 but has since been shown to be an issue in 2.6.34 also.
> > This fixes spurious firmware restarts that has been documented in
> > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2173 , but it is the
> > community report tracked in
> > https://bugzilla.kernel.org/show_bug.cgi?id=15782 that prompted us sending
> > this fix to wireless-2.6 also.
> >
> > These patches are also available from wireless-2.6 branch on
> > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
> >
> > Reinette Chatre (2):
> > iwlwifi: fix internal scan race
> > iwlagn: work around rate scaling reset delay
>
> Since the one of these is already in linux-2.6 now, I'll just apply
> the other one directly rather than pulling. I hope that isn't too
> inconvenient!
Makes sense to do this. No problem here. I'll work on getting them into
stable.
Thank you for the heads up.
Reinette
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-05-21 19:10 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bruno Randolf, David Quan, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com,
Luis Rodriguez, Sam Ng
In-Reply-To: <20100521171102.GA27736@tux>
On 2010-05-21 7:11 PM, Luis R. Rodriguez wrote:
> On Thu, May 20, 2010 at 06:59:33PM -0700, Bruno Randolf wrote:
>> so from my point of view this is not very different from what we can support
>> with the API i suggested. for RX it seems to be 100% equivalent.
>
> Well I agree, the API *supports it* but I want *clean, clear and consistant
> API*. And it just seems cleaner to separate the two.
>
>> the main difference as i see it is that with 802.11n you transmit on more than
>> one antenna, while with 'legacy' we can only transmit on one antenna at a
>> time.
>
> True, but note how the fact that you transmit over two antennas actually
> has regulatory implications. Now, ath9k handles this within ath9k_hw already
> but this itself seems like a worthy reason for this API to be separated.
> While I think it is great for ath9k_hw to do this, wouldn't it be nice
> if we can eventually instead expose the gain by using different chains
> at the same time and do the regulatory calculation for all devices within
> cfg80211?
>
>> actually i have to admit that on legacy "antenna set tx 3 (b11)" (select two
>> antennas for transmit) does not make much sense. i have defined it before as
>> "use diversity" but what about a different definition: like "bitmap of
>> antennas/chains to TRANSMIT".
>
> Right, and while that *works*, I think it would be clearer to just use a
> clear "diveristy" knob.
Splitting it by mode of operation (11n vs legacy) does not work, because
in AP mode you're doing both at the same time and there is an overlap in
both settings.
I think that Bruno's suggestion of keeping them as one setting makes
sense. About the regulatory concerns: where in the code does the
chainmask currently affect the regulatory constraints?
>> so for 802.11n that would allow you to select multiple trasmit chains.
>
> Instead of leaving the API to be interpreted by the mode of operation
> I think it would be much cleaner to just make your desires clearer and
> have the API define it well, and let the driver reject/accept it.
>
>> on legacy you are only allowed to select one antenna
>> in the bitmap. if it is set to "0" (or a separate flag) this could enable
>> "follow RX antenna diversity" on legacy.
>
> Sure that is one way, but it seems cleaner and easier for legacy purposes
> to just define an API that only fits legacy.
>
>> most of the other things you mention (need a reset/reassociate, regulatory
>> concerns...) are driver implementation issues, which can be dealt with in the
>> driver.
>
> Well so some of these things *could* be handled in mac80211 as well. For
> example, we may want to just dissociate upon a tx/rx chain setting change
> for all devices, but not for legacy. The regulatory stuff is another thing
> which could eventually be made more generic accross the board.
>
> Additionally, suppose you write an iw-tweak-gui thingy, and you want to
> provide expose tx/rx chainmask settings. Since some cards do not support
> some chainmask settings we may want to allow for a query of unsupported
> chainmasks and that way the GUI application could just grey-out the
> unsupported chainmask settings instead of letting the user figure out
> by trial and error that they are indeed not supported.
The API should just provide a bitmask of possible chains/antennas to
user space, which will be used as a mask for any values that the user
space sets. That's easy for a GUI utility to process
- Felix
^ permalink raw reply
* Re: [PATCH] wireless: fix sta_info.h kernel-doc warnings
From: Johannes Berg @ 2010-05-21 18:32 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20100521112841.86d6757c.randy.dunlap@oracle.com>
On Fri, 2010-05-21 at 11:28 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix sta_info.h kernel-doc warnings:
>
> Warning(net/mac80211/sta_info.h:164): No description found for parameter 'tid_active_rx[STA_TID_NUM]'
> Warning(net/mac80211/sta_info.h:164): Excess struct/union/enum/typedef member 'tid_state_rx' description in 'sta_ampdu_mlme'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks, and apologies for breaking this again.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> ---
> net/mac80211/sta_info.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.34-git6.orig/net/mac80211/sta_info.h
> +++ linux-2.6.34-git6/net/mac80211/sta_info.h
> @@ -145,7 +145,7 @@ enum plink_state {
> /**
> * struct sta_ampdu_mlme - STA aggregation information.
> *
> - * @tid_state_rx: TID's state in Rx session state machine.
> + * @tid_active_rx: TID's state in Rx session state machine.
> * @tid_rx: aggregation info for Rx per TID
> * @tid_state_tx: TID's state in Tx session state machine.
> * @tid_tx: aggregation info for Tx per TID
>
^ permalink raw reply
* [PATCH] wireless: fix sta_info.h kernel-doc warnings
From: Randy Dunlap @ 2010-05-21 18:28 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Johannes Berg
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix sta_info.h kernel-doc warnings:
Warning(net/mac80211/sta_info.h:164): No description found for parameter 'tid_active_rx[STA_TID_NUM]'
Warning(net/mac80211/sta_info.h:164): Excess struct/union/enum/typedef member 'tid_state_rx' description in 'sta_ampdu_mlme'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/sta_info.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.34-git6.orig/net/mac80211/sta_info.h
+++ linux-2.6.34-git6/net/mac80211/sta_info.h
@@ -145,7 +145,7 @@ enum plink_state {
/**
* struct sta_ampdu_mlme - STA aggregation information.
*
- * @tid_state_rx: TID's state in Rx session state machine.
+ * @tid_active_rx: TID's state in Rx session state machine.
* @tid_rx: aggregation info for Rx per TID
* @tid_state_tx: TID's state in Tx session state machine.
* @tid_tx: aggregation info for Tx per TID
^ permalink raw reply
* [PATCH] wireless: fix mac80211.h kernel-doc warnings
From: Randy Dunlap @ 2010-05-21 18:28 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix kernel-doc warnings in mac80211.h:
Warning(include/net/mac80211.h:838): No description found for parameter 'ap_addr'
Warning(include/net/mac80211.h:1726): No description found for parameter 'get_survey'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/net/mac80211.h | 3 +++
1 file changed, 3 insertions(+)
--- linux-2.6.34-git6.orig/include/net/mac80211.h
+++ linux-2.6.34-git6/include/net/mac80211.h
@@ -815,6 +815,7 @@ enum ieee80211_key_flags {
* encrypted in hardware.
* @alg: The key algorithm.
* @flags: key flags, see &enum ieee80211_key_flags.
+ * @ap_addr: AP's MAC address
* @keyidx: the key index (0-3)
* @keylen: key material length
* @key: key material. For ALG_TKIP the key is encoded as a 256-bit (32 byte)
@@ -1638,6 +1639,8 @@ enum ieee80211_ampdu_mlme_action {
* Returns a negative error code on failure.
* The callback must be atomic.
*
+ * @get_survey: Return per-channel survey information
+ *
* @rfkill_poll: Poll rfkill hardware state. If you need this, you also
* need to set wiphy->rfkill_poll to %true before registration,
* and need to call wiphy_rfkill_set_hw_state() in the callback.
^ permalink raw reply
* Re: [PATCH 0/2] iwlwifi fixes for 2.6.34
From: John W. Linville @ 2010-05-21 18:23 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linux-wireless, ipw3945-devel
In-Reply-To: <1273787385-9248-1-git-send-email-reinette.chatre@intel.com>
On Thu, May 13, 2010 at 02:49:43PM -0700, Reinette Chatre wrote:
> We include two late fixes hoping to make it into 2.6.34.
>
> "iwlwifi: fix internal scan race" fixes a kernel crash caused by
> accessing a NULL pointer. More can be read in
> https://bugzilla.kernel.org/show_bug.cgi?id=15824
>
> "iwlagn: work around rate scaling reset delay" is already in
> wireless-next-2.6 but has since been shown to be an issue in 2.6.34 also.
> This fixes spurious firmware restarts that has been documented in
> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2173 , but it is the
> community report tracked in
> https://bugzilla.kernel.org/show_bug.cgi?id=15782 that prompted us sending
> this fix to wireless-2.6 also.
>
> These patches are also available from wireless-2.6 branch on
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
>
> Reinette Chatre (2):
> iwlwifi: fix internal scan race
> iwlagn: work around rate scaling reset delay
Since the one of these is already in linux-2.6 now, I'll just apply
the other one directly rather than pulling. I hope that isn't too
inconvenient!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Iwlwifi and LEDS?
From: Abhijeet Kolekar @ 2010-05-21 18:07 UTC (permalink / raw)
To: Gregy; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikB8WaMyIj6CTY5wfEeVDratQ1Y8W3B_JBVllBp@mail.gmail.com>
On Fri, 2010-05-21 at 02:11 -0700, Gregy wrote:
> Hello, I noticed you removed support for led subsystem from iwlwifi. I
> have used it to control wifi led from userspace. Is it still possible
> somehow?
>
There is module parameter for iwlcore called 'led_mode'.
Abhijeet
> Otherwise thank you for your work.
>
> Gregy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How the mac80211 handle "\0" essid?
From: leo liang @ 2010-05-21 18:05 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless
In-Reply-To: <1274387415.1422.33.camel@localhost.localdomain>
On Thu, May 20, 2010 at 4:30 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Thu, 2010-05-20 at 15:40 -0400, leo liang wrote:
>> Hi,
>>
>> Does any one know that if the application send "\0" as essid to
>> mac80211, how it handle this case?
>
> What are you trying to do? Are you trying to work with a hidden AP, or
> do something else?
I want to hide the associated AP name. Or disassociate and do not let
the interface connect to any AP.
>
> An SSID is simply a 32-byte array; the protocol and the stack don't care
> what's in that array. So while you can't use command-line tools like
> 'iwconfig' to send an SSID containing a \0, you can use netlink or
> wpa_supplicant's nl80211 driver to do so.
I checked "iwconfig" source code, if you run "iwconfig wlan0 essid
off", it will set the first char as "\0".
>
> But in the end, if you're trying to associate with an AP that has an
> SSID of only '\0', that AP is likely broken or trying to hide it's SSID,
> and you should be using the real SSID of that AP instead of '\0'.
>
> Dan
>
>
>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-21 17:11 UTC (permalink / raw)
To: Bruno Randolf
Cc: Luis Rodriguez, David Quan, Sam Ng, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <201005211059.34081.br1@einfach.org>
On Thu, May 20, 2010 at 06:59:33PM -0700, Bruno Randolf wrote:
> On Friday 21 May 2010 07:05:48 Luis R. Rodriguez wrote:
> > For legacy, keep it simple, use 3 settings, fixed_a, fixed_b,
> > diversity, for all devices.
>
> did you not understand my examples why i think it makes sense to use a bitmask
> for "legacy"? i think they are perfectly valid use-cases. do i need to re-
> iterate them a third time?
Hehe, well from what I gather is that you indicate some other legacy cards
would have a very different setup than the typical two anntennas and
diversity modes. I see those cases as being reallllllly rare and not
worth considering. Did I miss anything, if so please smack me.
> > Lets use a different API for 802.11n. Reason being that even the case
> > I mentioned of an 802.11n device connecting on a legacy network needs
> > to be treated differently actually.
> >
> > For 802.11n you have a few more considerations. You can actually TX at
> > the same time on two or more different antennas at the same time. The
> > data you transmit will be the contents on both chains on a dual stream
> > device. So both antenna 0 and antenna 1 will both be transmitting the
> > data for both stream 0 and stream 1. As it turns out the combination
> > of TX'ing on two antennas at the same time at a certain dBm power will
> > yield a higher received frame on the RX side. This is why when you use
> > multiple chains you have to take regulatory rules into considerations
> > as well, since adding more chains will increase the overall output
> > power. Today ath9k handles this itself since this data is calibrated
> > but the max EIRP is passed out from cfg80211. Devices which do not
> > deal with these regulatory considerations likely won't support
> > changing chainmasks unless they use an API to respect regulatory
> > internally somehow. Perhaps the iwlagn firmware does this, beats me.
> >
> > The right terminology for antenna control for both TX and RX is
> > chainmask and a bitmap of 8 will suffice for existing hardware and up
> > to the not-yet-existant 600mbps 4 stream devices. Supporting 8 bits
> > will support up to 8 streams and we do not envision using beyond that
> > at this point. There is some considerations in the future for
> > supporting something other than HT40, like maybe HT80 and so forth but
> > those things won't be using more streams it seems.
> >
> > Then, some devices won't support all possible chainmask settings. This
> > will vary depending on the chipset. I work for Atheros so I can only
> > tell you what we can support, we'll have to check with the Intel folks
> > about their chipset limitations and settings.
> >
> > AR5416, AR5418 can only support chainmask settings which always keep
> > the first chain on. The AR9001 family and beyond cannot support the
> > 0b110 chaimask (David, you had pointed out some other restrictions,
> > what were they again?), the details are complex and I did not get a
> > chance to review them.
> >
> > I would not be surprised if other vendors had similar restrictions so
> > I'm thinking maybe we can express this as a requirement mask, or a set
> > of requirement masks. This way userspace utilities for debugging would
> > only expose certain chainmask settings.
> >
> > Now technically then you can incorporate the legacy API with the
> > 802.11n API here somehow but it just seems cleaner to keep them
> > separate.
> >
> > Also, David indicated that when we change the chainmask when are are
> > associated we have to do an actual chip reset, this is different than
> > the antenna diversity settings which an be done on the fly. We likely
> > will need to reassociate for a chainmask setting, not sure.
>
> so from my point of view this is not very different from what we can support
> with the API i suggested. for RX it seems to be 100% equivalent.
Well I agree, the API *supports it* but I want *clean, clear and consistant
API*. And it just seems cleaner to separate the two.
> the main difference as i see it is that with 802.11n you transmit on more than
> one antenna, while with 'legacy' we can only transmit on one antenna at a
> time.
True, but note how the fact that you transmit over two antennas actually
has regulatory implications. Now, ath9k handles this within ath9k_hw already
but this itself seems like a worthy reason for this API to be separated.
While I think it is great for ath9k_hw to do this, wouldn't it be nice
if we can eventually instead expose the gain by using different chains
at the same time and do the regulatory calculation for all devices within
cfg80211?
> actually i have to admit that on legacy "antenna set tx 3 (b11)" (select two
> antennas for transmit) does not make much sense. i have defined it before as
> "use diversity" but what about a different definition: like "bitmap of
> antennas/chains to TRANSMIT".
Right, and while that *works*, I think it would be clearer to just use a
clear "diveristy" knob.
> so for 802.11n that would allow you to select multiple trasmit chains.
Instead of leaving the API to be interpreted by the mode of operation
I think it would be much cleaner to just make your desires clearer and
have the API define it well, and let the driver reject/accept it.
> on legacy you are only allowed to select one antenna
> in the bitmap. if it is set to "0" (or a separate flag) this could enable
> "follow RX antenna diversity" on legacy.
Sure that is one way, but it seems cleaner and easier for legacy purposes
to just define an API that only fits legacy.
> most of the other things you mention (need a reset/reassociate, regulatory
> concerns...) are driver implementation issues, which can be dealt with in the
> driver.
Well so some of these things *could* be handled in mac80211 as well. For
example, we may want to just dissociate upon a tx/rx chain setting change
for all devices, but not for legacy. The regulatory stuff is another thing
which could eventually be made more generic accross the board.
Additionally, suppose you write an iw-tweak-gui thingy, and you want to
provide expose tx/rx chainmask settings. Since some cards do not support
some chainmask settings we may want to allow for a query of unsupported
chainmasks and that way the GUI application could just grey-out the
unsupported chainmask settings instead of letting the user figure out
by trial and error that they are indeed not supported.
> i would just suggest to let the driver reject antenna/chainmask
> configurations which it cannot support.
The unified API works, but I think we can provide a cleaner API
if we split them. What real benefit do we get if we keep them together?
I just imagine this resulting in more convoluted code.
Luis
^ permalink raw reply
* Re: Decrease transmission power in wireless cards
From: Bob Beers @ 2010-05-21 13:44 UTC (permalink / raw)
To: VivekKumar Singh; +Cc: linux-wireless
In-Reply-To: <AANLkTinSAFUTe4J2KlTors83uadU7diu2UI5rKCoKifO@mail.gmail.com>
On Fri, May 21, 2010 at 12:17 AM, VivekKumar Singh
<vivekkumar.singh@iiitb.net> wrote:
> Hi Friends,
>
> Please tell me how to reduce transmission power of wireless cards when
> card is in running mode?
I don't know the answer, but google found this, as the third hit of
"ath5k tx power":
<http://kerneltrap.org/mailarchive/linux-ath5k-devel/2010/3/5/6830713>
Or you could remove the antenna.
What are you trying to accomplish?
What have you tried?
What wireless card/driver?
What kernel?
What distribution?
-Bob
^ permalink raw reply
* [RFC PATCH 1/1] cfg80211: Fix user-space crda query stall
From: Juuso Oikarinen @ 2010-05-21 10:42 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1274438539-11259-1-git-send-email-juuso.oikarinen@nokia.com>
The userspace crda utility can fail to respond to kernel requests in (at least)
two scenarios: it is not runnable for any reason, or it is invoked with a
country code not in its database.
When the userspace crda utility fails to respond to kernel requests (i.e. it
does not use NL80211_CMD_SET_REG to provide the kernel regulatory information
for the requested country) the kernel crda subsystem will stall. It will
refuse to process any further regulatory hints. This is easiest demonstrated
by using for instance the "iw" tool:
iw reg set EU
iw reg set US
"EU" is not a country code present in the database, so user space crda will
not respond. Attempting to define US after that will be silently ignored
(internally, an -EAGAIN is the result, as the "EU" request is still
"being processed".)
To fix this issue, this patch implements timeout protection for the userspace
crda invocation. If there is no response for five seconds, the crda code will
force itself to the world regulatory domain for maximum safety.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
net/wireless/reg.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 8f0d97d..6e72f90 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -385,6 +385,41 @@ static inline void reg_regdb_query(const char *alpha2) {}
#endif /* CONFIG_CFG80211_INTERNAL_REGDB */
/*
+ * This gets invoked if crda in userspace is not responding (it's not getting
+ * executed or the country code in the hint is not in the database.
+ */
+
+static void call_crda_timeout_work(struct work_struct *work)
+{
+ if (!last_request)
+ return;
+
+ printk(KERN_INFO "cfg80211: Call crda daemon timed out for country: "
+ "%c%c\n", last_request->alpha2[0], last_request->alpha2[1]);
+
+ mutex_lock(&cfg80211_mutex);
+
+ /*
+ * As we are not getting data for the current country, force us back
+ * to the world regdomain.
+ */
+ last_request->alpha2[0] = '0';
+ last_request->alpha2[1] = '0';
+ set_regdom(cfg80211_world_regdom);
+ mutex_unlock(&cfg80211_mutex);
+}
+
+static DECLARE_WORK(crda_uevent_timeout_work, call_crda_timeout_work);
+
+#define CRDA_UEVENT_TIMEOUT 5000
+static void crda_uevent_timeout(unsigned long data)
+{
+ schedule_work(&crda_uevent_timeout_work);
+}
+
+static DEFINE_TIMER(crda_uevent_timer, crda_uevent_timeout, 0, 0);
+
+/*
* This lets us keep regulatory code which is updated on a regulatory
* basis in userspace.
*/
@@ -409,6 +444,10 @@ static int call_crda(const char *alpha2)
country_env[8] = alpha2[0];
country_env[9] = alpha2[1];
+ /* start timeout timer */
+ mod_timer(&crda_uevent_timer,
+ jiffies + msecs_to_jiffies(CRDA_UEVENT_TIMEOUT));
+
return kobject_uevent_env(®_pdev->dev.kobj, KOBJ_CHANGE, envp);
}
@@ -2581,6 +2620,9 @@ int set_regdom(const struct ieee80211_regdomain *rd)
assert_cfg80211_lock();
+ /* cancel timeout */
+ del_timer(&crda_uevent_timer);
+
mutex_lock(®_mutex);
/* Note that this doesn't update the wiphys, this is done below */
@@ -2683,6 +2725,9 @@ void regulatory_exit(void)
cancel_work_sync(®_work);
+ del_timer_sync(&crda_uevent_timer);
+ cancel_work_sync(&crda_uevent_timeout_work);
+
mutex_lock(&cfg80211_mutex);
mutex_lock(®_mutex);
--
1.6.3.3
^ permalink raw reply related
* [RFC PATCH 0/1] cfg80211: Fix user-space crda query stall
From: Juuso Oikarinen @ 2010-05-21 10:42 UTC (permalink / raw)
To: linux-wireless
When the user-space crda daemon fails to respond to kernel queries, the kernel
crda subsystem will stall, refusing any further regulatory hints. Details are
in the description of the patch itself.
The patch proposes a fix to the problem by adding a timeout to the user-space
crda accesses, reverting to the 00 domain if user space fails to respond. This
seems safe assuming we don't know what the rules of the requested domain and
allows further regulatory hints to be processed again.
In my testing, this patch appears to function in the various scenarios I can
produce (user hints and 11d hints.) My understanding of the crda subsystem is
still relatively shallow, so I'm asking for your thoughts on this approach.
Comments will be appreaciated!
Juuso Oikarinen (1):
cfg80211: Fix user-space crda query stall
net/wireless/reg.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
^ permalink raw reply
* Iwlwifi and LEDS?
From: Gregy @ 2010-05-21 9:11 UTC (permalink / raw)
To: linux-wireless
Hello, I noticed you removed support for led subsystem from iwlwifi. I
have used it to control wifi led from userspace. Is it still possible
somehow?
Otherwise thank you for your work.
Gregy
^ permalink raw reply
* carl9170 1.0.6
From: David H. Lynch Jr. @ 2010-05-21 7:50 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201005021452.01101.chunkeey@googlemail.com>
firmware_ssource/include/config.h
tests CARL9170_TX_STATUS_NUM - the number of status entries in the
response to see if it is an even number.
Does the max number of status entries actually have to be even ?
I had to add a fill byte to tx_status to get an even result.
> BUILD_BUG_ON(CARL9170_TX_STATUS_NUM % 2 || !CARL9170_TX_STATUS_NUM);
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.587.7774 dhlii@dlasys.net http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies
toonumerous to list.
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction."
Albert Einstein
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Decrease transmission power in wireless cards
From: VivekKumar Singh @ 2010-05-21 4:17 UTC (permalink / raw)
To: linux-wireless
Hi Friends,
Please tell me how to reduce transmission power of wireless cards when
card is in running mode?
--
Thanks and Regards,
Vivek Kumar Singh
MT-2009146
IIITB, Bangalore
(91)9886317184
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-05-21 1:59 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: David Quan, Sam Ng, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <AANLkTinPVSkrawZ4OCjp6vb-f4bA7nSrmnXjRDi-Pvvm@mail.gmail.com>
On Friday 21 May 2010 07:05:48 Luis R. Rodriguez wrote:
> For legacy, keep it simple, use 3 settings, fixed_a, fixed_b,
> diversity, for all devices.
did you not understand my examples why i think it makes sense to use a bitmask
for "legacy"? i think they are perfectly valid use-cases. do i need to re-
iterate them a third time?
> Lets use a different API for 802.11n. Reason being that even the case
> I mentioned of an 802.11n device connecting on a legacy network needs
> to be treated differently actually.
>
> For 802.11n you have a few more considerations. You can actually TX at
> the same time on two or more different antennas at the same time. The
> data you transmit will be the contents on both chains on a dual stream
> device. So both antenna 0 and antenna 1 will both be transmitting the
> data for both stream 0 and stream 1. As it turns out the combination
> of TX'ing on two antennas at the same time at a certain dBm power will
> yield a higher received frame on the RX side. This is why when you use
> multiple chains you have to take regulatory rules into considerations
> as well, since adding more chains will increase the overall output
> power. Today ath9k handles this itself since this data is calibrated
> but the max EIRP is passed out from cfg80211. Devices which do not
> deal with these regulatory considerations likely won't support
> changing chainmasks unless they use an API to respect regulatory
> internally somehow. Perhaps the iwlagn firmware does this, beats me.
>
> The right terminology for antenna control for both TX and RX is
> chainmask and a bitmap of 8 will suffice for existing hardware and up
> to the not-yet-existant 600mbps 4 stream devices. Supporting 8 bits
> will support up to 8 streams and we do not envision using beyond that
> at this point. There is some considerations in the future for
> supporting something other than HT40, like maybe HT80 and so forth but
> those things won't be using more streams it seems.
>
> Then, some devices won't support all possible chainmask settings. This
> will vary depending on the chipset. I work for Atheros so I can only
> tell you what we can support, we'll have to check with the Intel folks
> about their chipset limitations and settings.
>
> AR5416, AR5418 can only support chainmask settings which always keep
> the first chain on. The AR9001 family and beyond cannot support the
> 0b110 chaimask (David, you had pointed out some other restrictions,
> what were they again?), the details are complex and I did not get a
> chance to review them.
>
> I would not be surprised if other vendors had similar restrictions so
> I'm thinking maybe we can express this as a requirement mask, or a set
> of requirement masks. This way userspace utilities for debugging would
> only expose certain chainmask settings.
>
> Now technically then you can incorporate the legacy API with the
> 802.11n API here somehow but it just seems cleaner to keep them
> separate.
>
> Also, David indicated that when we change the chainmask when are are
> associated we have to do an actual chip reset, this is different than
> the antenna diversity settings which an be done on the fly. We likely
> will need to reassociate for a chainmask setting, not sure.
so from my point of view this is not very different from what we can support
with the API i suggested. for RX it seems to be 100% equivalent.
the main difference as i see it is that with 802.11n you transmit on more than
one antenna, while with 'legacy' we can only transmit on one antenna at a
time.
actually i have to admit that on legacy "antenna set tx 3 (b11)" (select two
antennas for transmit) does not make much sense. i have defined it before as
"use diversity" but what about a different definition: like "bitmap of
antennas/chains to TRANSMIT". so for 802.11n that would allow you to select
multiple trasmit chains. on legacy you are only allowed to select one antenna
in the bitmap. if it is set to "0" (or a separate flag) this could enable
"follow RX antenna diversity" on legacy.
most of the other things you mention (need a reset/reassociate, regulatory
concerns...) are driver implementation issues, which can be dealt with in the
driver. i would just suggest to let the driver reject antenna/chainmask
configurations which it cannot support.
bruno
^ permalink raw reply
* Re: [PATCH] ath9k_htc: Use proper station add/remove callbacks
From: Luis R. Rodriguez @ 2010-05-21 0:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sujith, linville, linux-wireless
In-Reply-To: <1274181228.3762.78.camel@jlt3.sipsolutions.net>
On Tue, May 18, 2010 at 4:13 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-05-18 at 15:26 +0530, Sujith wrote:
>> sta_add/sta_remove are the callbacks that can sleep.
>> Use them instead of sta_notify.
>>
>> Sigh. What a dumb fsckup.
>
> Not really your fault? The sleeping ones are quite new.
John, this fix might be a 2.6.35 fix although not noted as such.
Luis
^ permalink raw reply
* Re: How to scan APs with ATH5k?
From: Bob Copeland @ 2010-05-20 22:46 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Jaroslav Fojtik, linux-wireless
In-Reply-To: <1274392411.7054.6.camel@mj>
On Thu, May 20, 2010 at 05:53:31PM -0400, Pavel Roskin wrote:
> On Thu, 2010-05-20 at 21:28 +0200, Jaroslav Fojtik wrote:
> It looks like a bug. Even if something is preventing scanning, the
> error code should be -EBUSY (device busy).
>
> The same is true for ath9k, but I cannot test ath5k at the moment.
> mac80211 does a considerable effort to allow scanning while associated.
It's certainly something that used to work, but I haven't tried in
a recent kernel. So yes probably a bug.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-20 22:24 UTC (permalink / raw)
To: Sam Ng
Cc: Luis Rodriguez, Bruno Randolf, David Quan,
ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <BD672EAEE3AD2C47A7120B0973C3FB3A2DC1C779ED@SC1EXMB-MBCL.global.atheros.com>
Just for clarification, these e-mails are on a public mailing list.
On Thu, May 20, 2010 at 03:14:01PM -0700, Sam Ng wrote:
> Just to be accurate, we do have pre-lln devices that support
> more than 1 antenna ie. slow/fast diversity
Right, this is the typical fixed anntena a, fixed anntena b, or
antenna diversity mode.
> and rangemax style 'beamforming'. However, all these devices
> have only 1 chain.
Thanks for the clarification Sam.
Luis
^ permalink raw reply
* RE: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Sam Ng @ 2010-05-20 22:14 UTC (permalink / raw)
To: Luis Rodriguez, Bruno Randolf, David Quan
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <AANLkTinPVSkrawZ4OCjp6vb-f4bA7nSrmnXjRDi-Pvvm@mail.gmail.com>
SnVzdCB0byBiZSBhY2N1cmF0ZSwgd2UgZG8gaGF2ZSBwcmUtbGxuIGRldmljZXMgdGhhdCBzdXBw
b3J0IG1vcmUgdGhhbiAxIGFudGVubmEgaWUuIHNsb3cvZmFzdCBkaXZlcnNpdHkgYW5kDQpyYW5n
ZW1heCBzdHlsZSAnYmVhbWZvcm1pbmcnLiBIb3dldmVyLCBhbGwgdGhlc2UgZGV2aWNlcyBoYXZl
IG9ubHkgMSBjaGFpbi4NCg0KU2FtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBtY2dyb2ZAZ21haWwuY29tIFttYWlsdG86bWNncm9mQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9m
IEx1aXMgUi4gUm9kcmlndWV6DQpTZW50OiBUaHVyc2RheSwgTWF5IDIwLCAyMDEwIDM6MDYgUE0N
ClRvOiBCcnVubyBSYW5kb2xmOyBEYXZpZCBRdWFuOyBTYW0gTmcNCkNjOiBhdGg1ay1kZXZlbEBs
aXN0cy5hdGg1ay5vcmc7IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZzsgbGludmlsbGVA
dHV4ZHJpdmVyLmNvbQ0KU3ViamVjdDogUmU6IFthdGg1ay1kZXZlbF0gW1BBVENIIHYyIDEzLzIw
XSBjZmc4MDIxMTogQWRkIG5sODAyMTEgYW50ZW5uYSBjb25maWd1cmF0aW9uDQoNCk9uIFdlZCwg
TWF5IDE5LCAyMDEwIGF0IDExOjQzIFBNLCBMdWlzIFIuIFJvZHJpZ3Vleg0KPGxyb2RyaWd1ZXpA
YXRoZXJvcy5jb20+IHdyb3RlOg0KPiBPbiBXZWQsIE1heSAxOSwgMjAxMCBhdCAxMDozNiBQTSwg
QnJ1bm8gUmFuZG9sZiA8YnIxQGVpbmZhY2gub3JnPiB3cm90ZToNCj4+IE9uIFRodXJzZGF5IDIw
IE1heSAyMDEwIDE0OjE3OjE5IHlvdSB3cm90ZToNCj4+PiBOb25lIG9mIHRoZSBsZWdhY3kgODAy
LjExIGRyaXZlcnMgd2Ugc3VwcG9ydCBoYXZlIG1vcmUgdGhhbiAyDQo+Pj4gYW50ZW5uYXMsIEkg
YW0gYWxzbyBub3QgYXdhcmUgb2YgYW55Lg0KPj4NCj4+IGkgaGF2ZSBoZWFyZCBvZiBzb21lIHNv
bHV0aW9ucyBiYXNlZCBvbiBhdGhlcm9zIGNoaXBzZXRzIHdpdGggbW9yZSB0aGFuIDINCj4+IGFu
dGVubmFzICgicHJlLTExbiBSYW5nZU1heCIsICJsYXJnZSBwaGFzZWQgYXJyYXkgc3dpdGNoIiku
IHBsZWFzZSBjaGVjaw0KPj4gaW50ZXJuYWxseS4NCj4NCj4gSSB3aWxsLiBEYXZpZCwgYXJlIHlv
dSBhd2FyZSBvZiBsZWdhY3kgKG5vbiA4MDIuMTFuKSBkZXZpY2VzIHdpdGggbW9yZQ0KPiB0aGFu
IDIgYW50ZW5uYXM/DQoNCkkgcGlja2VkIERhdmlkJ3MgYnJhaW4gYW5kIHdlJ3JlIHByZXR0eSBj
ZXJ0YWluIHRoZXNlIGRldmljZXMgZG8gbm90DQpleGlzdCBpbiB0aGUgbWFya2V0Lg0KDQo+Pj4g
WW91J3JlIHJpZ2h0LCB0aGVuIGlmIHlvdSByZWFsbHkgZG9uJ3QgbWluZCBsZXRzIHRoaW5rIDgw
Mi4xMW4gdGhyb3VnaA0KPj4+IHdlbGwgdGhlbi4NCj4+DQo+PiBpIGRvbid0IG1pbmQgdG8gZG8g
dGhhdCwgYnV0IGFzIGkgc2FpZCBpIGRvbnQga25vdyBtdWNoIGFib3V0IDgwMi4xMW4geWV0Lg0K
Pg0KPiBUaGFua3MsIGdpdmUgbWUgc29tZSB0aW1lIHRvIHRoaW5rIGFib3V0IHRoaXMgdGhlbiBh
bmQgZ2V0IGJhY2sgdG8geW91Lg0KDQpPSyBzbyBiYWNrIHRvIHRoZSBkcmF3aW5nIGJvYXJkLCB0
aGlzIGlzIHdoYXQgSSByZWNvbW1lbmQ6DQoNCkZvciBsZWdhY3ksIGtlZXAgaXQgc2ltcGxlLCB1
c2UgMyBzZXR0aW5ncywgZml4ZWRfYSwgZml4ZWRfYiwNCmRpdmVyc2l0eSwgZm9yIGFsbCBkZXZp
Y2VzLg0KDQpMZXRzIHVzZSBhIGRpZmZlcmVudCBBUEkgZm9yIDgwMi4xMW4uIFJlYXNvbiBiZWlu
ZyB0aGF0IGV2ZW4gdGhlIGNhc2UNCkkgbWVudGlvbmVkIG9mIGFuIDgwMi4xMW4gZGV2aWNlIGNv
bm5lY3Rpbmcgb24gYSBsZWdhY3kgbmV0d29yayBuZWVkcw0KdG8gYmUgdHJlYXRlZCBkaWZmZXJl
bnRseSBhY3R1YWxseS4NCg0KRm9yIDgwMi4xMW4geW91IGhhdmUgYSBmZXcgbW9yZSBjb25zaWRl
cmF0aW9ucy4gWW91IGNhbiBhY3R1YWxseSBUWCBhdA0KdGhlIHNhbWUgdGltZSBvbiB0d28gb3Ig
bW9yZSBkaWZmZXJlbnQgYW50ZW5uYXMgYXQgdGhlIHNhbWUgdGltZS4gVGhlDQpkYXRhIHlvdSB0
cmFuc21pdCB3aWxsIGJlIHRoZSBjb250ZW50cyBvbiBib3RoIGNoYWlucyBvbiBhIGR1YWwgc3Ry
ZWFtDQpkZXZpY2UuIFNvIGJvdGggYW50ZW5uYSAwIGFuZCBhbnRlbm5hIDEgd2lsbCBib3RoIGJl
IHRyYW5zbWl0dGluZyB0aGUNCmRhdGEgZm9yIGJvdGggc3RyZWFtIDAgYW5kIHN0cmVhbSAxLiBB
cyBpdCB0dXJucyBvdXQgdGhlIGNvbWJpbmF0aW9uDQpvZiBUWCdpbmcgb24gdHdvIGFudGVubmFz
IGF0IHRoZSBzYW1lIHRpbWUgYXQgYSBjZXJ0YWluIGRCbSBwb3dlciB3aWxsDQp5aWVsZCBhIGhp
Z2hlciByZWNlaXZlZCBmcmFtZSBvbiB0aGUgUlggc2lkZS4gVGhpcyBpcyB3aHkgd2hlbiB5b3Ug
dXNlDQptdWx0aXBsZSBjaGFpbnMgeW91IGhhdmUgdG8gdGFrZSByZWd1bGF0b3J5IHJ1bGVzIGlu
dG8gY29uc2lkZXJhdGlvbnMNCmFzIHdlbGwsIHNpbmNlIGFkZGluZyBtb3JlIGNoYWlucyB3aWxs
IGluY3JlYXNlIHRoZSBvdmVyYWxsIG91dHB1dA0KcG93ZXIuIFRvZGF5IGF0aDlrIGhhbmRsZXMg
dGhpcyBpdHNlbGYgc2luY2UgdGhpcyBkYXRhIGlzIGNhbGlicmF0ZWQNCmJ1dCB0aGUgbWF4IEVJ
UlAgaXMgcGFzc2VkIG91dCBmcm9tIGNmZzgwMjExLiBEZXZpY2VzIHdoaWNoIGRvIG5vdA0KZGVh
bCB3aXRoIHRoZXNlIHJlZ3VsYXRvcnkgY29uc2lkZXJhdGlvbnMgbGlrZWx5IHdvbid0IHN1cHBv
cnQNCmNoYW5naW5nIGNoYWlubWFza3MgdW5sZXNzIHRoZXkgdXNlIGFuIEFQSSB0byByZXNwZWN0
IHJlZ3VsYXRvcnkNCmludGVybmFsbHkgc29tZWhvdy4gUGVyaGFwcyB0aGUgaXdsYWduIGZpcm13
YXJlIGRvZXMgdGhpcywgYmVhdHMgbWUuDQoNClRoZSByaWdodCB0ZXJtaW5vbG9neSBmb3IgYW50
ZW5uYSBjb250cm9sIGZvciBib3RoIFRYIGFuZCBSWCBpcw0KY2hhaW5tYXNrIGFuZCBhIGJpdG1h
cCBvZiA4IHdpbGwgc3VmZmljZSBmb3IgZXhpc3RpbmcgaGFyZHdhcmUgYW5kIHVwDQp0byB0aGUg
bm90LXlldC1leGlzdGFudCA2MDBtYnBzIDQgc3RyZWFtIGRldmljZXMuIFN1cHBvcnRpbmcgOCBi
aXRzDQp3aWxsIHN1cHBvcnQgdXAgdG8gOCBzdHJlYW1zIGFuZCB3ZSBkbyBub3QgZW52aXNpb24g
dXNpbmcgYmV5b25kIHRoYXQNCmF0IHRoaXMgcG9pbnQuIFRoZXJlIGlzIHNvbWUgY29uc2lkZXJh
dGlvbnMgaW4gdGhlIGZ1dHVyZSBmb3INCnN1cHBvcnRpbmcgc29tZXRoaW5nIG90aGVyIHRoYW4g
SFQ0MCwgbGlrZSBtYXliZSBIVDgwIGFuZCBzbyBmb3J0aCBidXQNCnRob3NlIHRoaW5ncyB3b24n
dCBiZSB1c2luZyBtb3JlIHN0cmVhbXMgaXQgc2VlbXMuDQoNClRoZW4sIHNvbWUgZGV2aWNlcyB3
b24ndCBzdXBwb3J0IGFsbCBwb3NzaWJsZSBjaGFpbm1hc2sgc2V0dGluZ3MuIFRoaXMNCndpbGwg
dmFyeSBkZXBlbmRpbmcgb24gdGhlIGNoaXBzZXQuIEkgd29yayBmb3IgQXRoZXJvcyBzbyBJIGNh
biBvbmx5DQp0ZWxsIHlvdSB3aGF0IHdlIGNhbiBzdXBwb3J0LCB3ZSdsbCBoYXZlIHRvIGNoZWNr
IHdpdGggdGhlIEludGVsIGZvbGtzDQphYm91dCB0aGVpciBjaGlwc2V0IGxpbWl0YXRpb25zIGFu
ZCBzZXR0aW5ncy4NCg0KQVI1NDE2LCBBUjU0MTggY2FuIG9ubHkgc3VwcG9ydCBjaGFpbm1hc2sg
c2V0dGluZ3Mgd2hpY2ggYWx3YXlzIGtlZXANCnRoZSBmaXJzdCBjaGFpbiBvbi4gVGhlIEFSOTAw
MSBmYW1pbHkgYW5kIGJleW9uZCBjYW5ub3Qgc3VwcG9ydCB0aGUNCjBiMTEwIGNoYWltYXNrIChE
YXZpZCwgeW91IGhhZCBwb2ludGVkIG91dCBzb21lIG90aGVyIHJlc3RyaWN0aW9ucywNCndoYXQg
d2VyZSB0aGV5IGFnYWluPyksIHRoZSBkZXRhaWxzIGFyZSBjb21wbGV4IGFuZCBJIGRpZCBub3Qg
Z2V0IGENCmNoYW5jZSB0byByZXZpZXcgdGhlbS4NCg0KSSB3b3VsZCBub3QgYmUgc3VycHJpc2Vk
IGlmIG90aGVyIHZlbmRvcnMgaGFkIHNpbWlsYXIgcmVzdHJpY3Rpb25zIHNvDQpJJ20gdGhpbmtp
bmcgbWF5YmUgd2UgY2FuIGV4cHJlc3MgdGhpcyBhcyBhIHJlcXVpcmVtZW50IG1hc2ssIG9yIGEg
c2V0DQpvZiByZXF1aXJlbWVudCBtYXNrcy4gVGhpcyB3YXkgdXNlcnNwYWNlIHV0aWxpdGllcyBm
b3IgZGVidWdnaW5nIHdvdWxkDQpvbmx5IGV4cG9zZSBjZXJ0YWluIGNoYWlubWFzayBzZXR0aW5n
cy4NCg0KTm93IHRlY2huaWNhbGx5IHRoZW4geW91IGNhbiBpbmNvcnBvcmF0ZSB0aGUgbGVnYWN5
IEFQSSB3aXRoIHRoZQ0KODAyLjExbiBBUEkgaGVyZSBzb21laG93IGJ1dCBpdCBqdXN0IHNlZW1z
IGNsZWFuZXIgdG8ga2VlcCB0aGVtDQpzZXBhcmF0ZS4NCg0KQWxzbywgRGF2aWQgaW5kaWNhdGVk
IHRoYXQgd2hlbiB3ZSBjaGFuZ2UgdGhlIGNoYWlubWFzayB3aGVuIGFyZSBhcmUNCmFzc29jaWF0
ZWQgd2UgaGF2ZSB0byBkbyBhbiBhY3R1YWwgY2hpcCByZXNldCwgdGhpcyBpcyBkaWZmZXJlbnQg
dGhhbg0KdGhlIGFudGVubmEgZGl2ZXJzaXR5IHNldHRpbmdzIHdoaWNoIGFuIGJlIGRvbmUgb24g
dGhlIGZseS4gV2UgbGlrZWx5DQp3aWxsIG5lZWQgdG8gcmVhc3NvY2lhdGUgZm9yIGEgY2hhaW5t
YXNrIHNldHRpbmcsIG5vdCBzdXJlLg0KDQogIEx1aXMNCg==
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-05-20 22:05 UTC (permalink / raw)
To: Bruno Randolf, David Quan, Sam Ng
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <AANLkTilk0CIkmmIsBzPwchd6EBIVavw9R1amiSgCZOrx@mail.gmail.com>
On Wed, May 19, 2010 at 11:43 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, May 19, 2010 at 10:36 PM, Bruno Randolf <br1@einfach.org> wrote:
>> On Thursday 20 May 2010 14:17:19 you wrote:
>>> None of the legacy 802.11 drivers we support have more than 2
>>> antennas, I am also not aware of any.
>>
>> i have heard of some solutions based on atheros chipsets with more than 2
>> antennas ("pre-11n RangeMax", "large phased array switch"). please check
>> internally.
>
> I will. David, are you aware of legacy (non 802.11n) devices with more
> than 2 antennas?
I picked David's brain and we're pretty certain these devices do not
exist in the market.
>>> You're right, then if you really don't mind lets think 802.11n through
>>> well then.
>>
>> i don't mind to do that, but as i said i dont know much about 802.11n yet.
>
> Thanks, give me some time to think about this then and get back to you.
OK so back to the drawing board, this is what I recommend:
For legacy, keep it simple, use 3 settings, fixed_a, fixed_b,
diversity, for all devices.
Lets use a different API for 802.11n. Reason being that even the case
I mentioned of an 802.11n device connecting on a legacy network needs
to be treated differently actually.
For 802.11n you have a few more considerations. You can actually TX at
the same time on two or more different antennas at the same time. The
data you transmit will be the contents on both chains on a dual stream
device. So both antenna 0 and antenna 1 will both be transmitting the
data for both stream 0 and stream 1. As it turns out the combination
of TX'ing on two antennas at the same time at a certain dBm power will
yield a higher received frame on the RX side. This is why when you use
multiple chains you have to take regulatory rules into considerations
as well, since adding more chains will increase the overall output
power. Today ath9k handles this itself since this data is calibrated
but the max EIRP is passed out from cfg80211. Devices which do not
deal with these regulatory considerations likely won't support
changing chainmasks unless they use an API to respect regulatory
internally somehow. Perhaps the iwlagn firmware does this, beats me.
The right terminology for antenna control for both TX and RX is
chainmask and a bitmap of 8 will suffice for existing hardware and up
to the not-yet-existant 600mbps 4 stream devices. Supporting 8 bits
will support up to 8 streams and we do not envision using beyond that
at this point. There is some considerations in the future for
supporting something other than HT40, like maybe HT80 and so forth but
those things won't be using more streams it seems.
Then, some devices won't support all possible chainmask settings. This
will vary depending on the chipset. I work for Atheros so I can only
tell you what we can support, we'll have to check with the Intel folks
about their chipset limitations and settings.
AR5416, AR5418 can only support chainmask settings which always keep
the first chain on. The AR9001 family and beyond cannot support the
0b110 chaimask (David, you had pointed out some other restrictions,
what were they again?), the details are complex and I did not get a
chance to review them.
I would not be surprised if other vendors had similar restrictions so
I'm thinking maybe we can express this as a requirement mask, or a set
of requirement masks. This way userspace utilities for debugging would
only expose certain chainmask settings.
Now technically then you can incorporate the legacy API with the
802.11n API here somehow but it just seems cleaner to keep them
separate.
Also, David indicated that when we change the chainmask when are are
associated we have to do an actual chip reset, this is different than
the antenna diversity settings which an be done on the fly. We likely
will need to reassociate for a chainmask setting, not sure.
Luis
^ permalink raw reply
* RE: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
From: David Quan @ 2010-05-20 22:02 UTC (permalink / raw)
To: Luis Rodriguez, Bruno Randolf
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <AANLkTilk0CIkmmIsBzPwchd6EBIVavw9R1amiSgCZOrx@mail.gmail.com>
rangemax is a proprietary design by netgear and their 3rd party, there is no way for us to control
their antenna array. yes, this is a legacy non 11n design with more than 2 antenna.
-----Original Message-----
From: mcgrof@gmail.com [mailto:mcgrof@gmail.com] On Behalf Of Luis R. Rodriguez
Sent: Wednesday, May 19, 2010 11:44 PM
To: Bruno Randolf; David Quan
Cc: ath5k-devel@lists.ath5k.org; linux-wireless@vger.kernel.org; linville@tuxdriver.com
Subject: Re: [ath5k-devel] [PATCH v2 13/20] cfg80211: Add nl80211 antenna configuration
On Wed, May 19, 2010 at 10:36 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Thursday 20 May 2010 14:17:19 you wrote:
>> None of the legacy 802.11 drivers we support have more than 2
>> antennas, I am also not aware of any.
>
> i have heard of some solutions based on atheros chipsets with more than 2
> antennas ("pre-11n RangeMax", "large phased array switch"). please check
> internally.
I will. David, are you aware of legacy (non 802.11n) devices with more
than 2 antennas?
>> But -- I can think of using an 802.11n device in legacy
>> mode of operation using specific antennas.... so there's your example
>> of a valid case for this.
>
> thanks! :)
>
>> Legacy devices are dead. I don't know anyone in the industry making
>> them, the 1 stream 802.11n devices are cheaper today, so there is no
>> point in the market for it.
>
> that might be true from a chipset manufacturers marketing perspective - but we
> work on the linux kernel... ;)
>
> as you know there are millions of so called "legacy" chipsets out there and
> people are going to continue to use them wether your marketing declares them
> "dead" or not... i think it's worth to properly support them.
>
> also please don't forget that some people use the linux kernel not just for
> standard use cases, but for research and developing new solutions. we should
> provide the flexibility to support that, if possible.
Heh, yeah but what goes into the Linux kernel are drivers for hardware
silicon companies make. Who is making new legacy chipsets still?
>> > and we are sure we don't want to support more than 2
>> > antennas - well, we could save 6 bits... is it really worth it?
>>
>> You're right, then if you really don't mind lets think 802.11n through
>> well then.
>
> i don't mind to do that, but as i said i dont know much about 802.11n yet.
Thanks, give me some time to think about this then and get back to you.
Luis
^ permalink raw reply
* Re: How to scan APs with ATH5k?
From: Pavel Roskin @ 2010-05-20 21:53 UTC (permalink / raw)
To: Jaroslav Fojtik; +Cc: linux-wireless, Bob Copeland
In-Reply-To: <4BF58D72.22852.D1D2D@jafojtik.seznam.cz>
On Thu, 2010-05-20 at 21:28 +0200, Jaroslav Fojtik wrote:
> Dear Bob,
>
> > $ sudo ifconfig wlan0 up
> > $ sudo iw dev wlan0 scan
>
> I have typed:
>
> ifconfig wlan0 down
> ifconfig wlan0 up
> iwlist wlan0 scanning
> (I do not have installed iw)
I think you should install iw and use it instead. Ideally, iwlist
should work as well, but iw would provide a useful datapoint.
> But when an interface wlan0 become associated, it refuses scanning.
>
> root@dvouramenna:~# iwlist wlan0 scanning
> wlan0 Interface doesn't support scanning : Operation not supported
>
>
> Is this bug or feature?
It looks like a bug. Even if something is preventing scanning, the
error code should be -EBUSY (device busy).
> MadWifi can scan even when interface is associated.
> ipw2200bg can also scan when it is associated.
The same is true for ath9k, but I cannot test ath5k at the moment.
mac80211 does a considerable effort to allow scanning while associated.
--
Regards,
Pavel Roskin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox