* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: Johannes Berg @ 2011-01-11 13:00 UTC (permalink / raw)
To: jpo234; +Cc: linux-wireless
In-Reply-To: <loom.20110111T135315-64@post.gmane.org>
On Tue, 2011-01-11 at 12:57 +0000, jpo234 wrote:
> Johannes Berg <johannes@...> writes:
> > because uint64_t isn't guaranteed to be unsigned long long (in fact, it
> > is unsigned long on many machines). Please look at the commit and check.
>
> In the commit you did a cast to unsigned long long. While this works, it's
> depends on gcc-ism, e.g. long long support. The C99 way would be to use the
> PRIu64 macro (see stdint.h).
> see http://www.dinkumware.com/manuals/?manual=compleat&page=inttypes.html#PRIu64
Oi, that's complicated. Patch welcome I guess.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211:mesh_mpp_table_grow call should depend on MESH_WORK_GROW_MPP_TABLE flag.
From: Johannes Berg @ 2011-01-11 12:59 UTC (permalink / raw)
To: nledovskikh; +Cc: linville, devel, linux-wireless
In-Reply-To: <20110111143512.8161042b.nledovskikh@kodofon.vrn.ru>
On Tue, 2011-01-11 at 14:35 +0000, Nick Ledovskikh wrote:
> Replace MESH_WORK_GROW_MPATH_TABLE by MESH_WORK_GROW_MPP_TABLE in
> mesh_mpp_table_grow call condition.
A changelog should explain "why" ... everybody can read "what" from the
patch already.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: jpo234 @ 2011-01-11 12:57 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1294734744.3611.3.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@...> writes:
> because uint64_t isn't guaranteed to be unsigned long long (in fact, it
> is unsigned long on many machines). Please look at the commit and check.
In the commit you did a cast to unsigned long long. While this works, it's
depends on gcc-ism, e.g. long long support. The C99 way would be to use the
PRIu64 macro (see stdint.h).
see http://www.dinkumware.com/manuals/?manual=compleat&page=inttypes.html#PRIu64
^ permalink raw reply
* [PATCH] mac80211:mesh_mpp_table_grow call should depend on MESH_WORK_GROW_MPP_TABLE flag.
From: Nick Ledovskikh @ 2011-01-11 14:35 UTC (permalink / raw)
To: linville; +Cc: devel, devel, linux-wireless
Replace MESH_WORK_GROW_MPATH_TABLE by MESH_WORK_GROW_MPP_TABLE in
mesh_mpp_table_grow call condition.
Signed-off-by: Nickolay Ledovskikh <nledovskikh@gmail.com>
---
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index ca3af46..2563fd1 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -645,7 +645,7 @@ void ieee80211_mesh_work(struct ieee80211_sub_if_data *sdata)
if (test_and_clear_bit(MESH_WORK_GROW_MPATH_TABLE, &ifmsh->wrkq_flags))
mesh_mpath_table_grow();
- if (test_and_clear_bit(MESH_WORK_GROW_MPATH_TABLE, &ifmsh->wrkq_flags))
+ if (test_and_clear_bit(MESH_WORK_GROW_MPP_TABLE, &ifmsh->wrkq_flags))
mesh_mpp_table_grow();
if (test_and_clear_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags))
--
Best regards, Nickolay Ledovskikh.
^ permalink raw reply related
* Re: [PATCH] cfg80211: Extend channel to frequency mapping for 802.11j
From: Johannes Berg @ 2011-01-11 12:18 UTC (permalink / raw)
To: Bruno Randolf
Cc: Brian Prodoehl, linville, linux-wireless, Dan Williams,
libertas-dev, Ivo van Doorn, Gertjan van Wingerde, users
In-Reply-To: <201101111817.40309.br1@einfach.org>
On Tue, 2011-01-11 at 18:17 +0900, Bruno Randolf wrote:
> > compat-wireless-2011-01-07.orig/drivers/net/wireless/libertas/cfg.c 2011-0
> > 1-07 15:03:59.000000000 -0500
> > +++
> > compat-wireless-2011-01-07/drivers/net/wireless/libertas/cfg.c 2011-01-08
> > 07:51:23.947290769 -0500
> > @@ -607,7 +607,8 @@
> > /* No channel, no luck */
> > if (chan_no != -1) {
> > struct wiphy *wiphy = priv->wdev->wiphy;
> > - int freq = ieee80211_channel_to_frequency(chan_no);
> > + int freq = ieee80211_channel_to_frequency(chan_no,
> > + chan_no <= 14 ? IEEE80211_BAND_2GHZ :
> IEEE80211_BAND_5GHZ);
>
> The whole point of having the band argument is to avoid this. We now have
> overlapping channel numbers: channel 8 and 12 are defined in 5GHz as well as
> in 2.4GHz (that is for 20MHz channel width, there are more for 10 and 5MHz
> width, but we don't support that yet). The band has to come from the hardware
> or driver configuration.
I don't think libertas (or orinoco) support the frequencies that
overlap, and they use the channel number in HW config, so it should be
fine.
johannes
^ permalink raw reply
* Re: packet injection not working on rt2800usb, ath9k
From: Jouni Malinen @ 2011-01-11 11:52 UTC (permalink / raw)
To: Andy Pyles; +Cc: linux-wireless
In-Reply-To: <AANLkTi=2N5A0ZBoULj3d0Bp_GeWQouHGFA_LRWWu1k22@mail.gmail.com>
On Mon, Jan 10, 2011 at 06:08:13PM -0500, Andy Pyles wrote:
> I'm using linux-wireless snapshot from December, 2010 with the
> following driver: rt2800usb
>
> The linux-wireless snapshot for ath9k is from last summer ( July)
> Question: Is this operation supported on these two devices? If not,
> what device can you recommend a device where this does work?
I do not know about rt2800usb, but monitor mode and packet injection
works with ath9k. I'm not sure how packetspammer is doing this, but at
least use of Linux packet socket and simple radiotap header works fine
in my tests. In addition, it could be useful to update your ath9k driver
to make sure you are running with all the latest fixes.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: wl12xx compat wireless rcu_read_lock issue
From: Luciano Coelho @ 2011-01-11 11:28 UTC (permalink / raw)
To: DE CESCO, Jonathan; +Cc: linux-wireless@vger.kernel.org, Arik Nemtsov
In-Reply-To: <13872098A06B02418CF379A158C0F146015BEB592B@dnce02.ent.ti.com>
On Tue, 2011-01-11 at 11:22 +0100, DE CESCO, Jonathan wrote:
> Hi,
>
> When trying to test wl12xx driver from compat-wireless-2010-12-13 (with a wl1273 device), I notice a crash when initializing the wlan interface.
>
> Find below the patch that seems to solve the issue:
>
> diff --git a/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c b/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c
> index 1fc5a36..480f44b 100644
> --- a/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c
> +++ b/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c
> @@ -1858,11 +1858,17 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
> {
> enum wl1271_cmd_ps_mode mode;
> struct wl1271 *wl = hw->priv;
> - struct ieee80211_sta *sta = ieee80211_find_sta(vif, bss_conf->bssid);
> + rcu_read_lock();
> + struct ieee80211_sta *sta;
> bool do_join = false;
> bool set_assoc = false;
> int ret;
>
> + sta = ieee80211_find_sta(vif, bss_conf->bssid);
> + if (!sta) {
> + rcu_read_unlock();
> + return;
> + }
>
> wl1271_debug(DEBUG_MAC80211, "mac80211 bss info changed");
> + rcu_read_unlock();
> mutex_lock(&wl->mutex);
>
> --
>
> Is this a known bug that has already been encountered? I am using the compat wireless flavor of the mac80211 framework and driver so I don't really know if you can come across this issue with standard kernel.
I hadn't seen it before, but then again, I just integrated the AP
patches which added this code. The code has been tested quite well
before, but indeed this is broken.
We need to lock the RCU before calling ieee80211_find_sta() and also
whenever we access the resulting pointer.
In your patch, the if (!sta) part is wrong, because we still do lots of
things in this function even if sta is NULL. So that if can be removed.
Also, because the RCU lock needs to be held when the returned pointer is
accessed, we should hold it until the end of the function.
>From mac80211 documentation:
/**
* ieee80211_find_sta - find a station
*
* @vif: virtual interface to look for station on
* @addr: station's address
*
* This function must be called under RCU lock and the
* resulting pointer is only valid under RCU lock as well.
*/
Thanks for reporting this!
--
Cheers,
Luca.
^ permalink raw reply
* wl12xx compat wireless rcu_read_lock issue
From: DE CESCO, Jonathan @ 2011-01-11 10:22 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Coelho, Luciano
In-Reply-To: <AANLkTimpDo=0AcL5OdEjnpB8-_o7XBJ5QT-mE-FmfZo6@mail.gmail.com>
Hi,
When trying to test wl12xx driver from compat-wireless-2010-12-13 (with a wl1273 device), I notice a crash when initializing the wlan interface.
Find below the patch that seems to solve the issue:
diff --git a/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c b/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c
index 1fc5a36..480f44b 100644
--- a/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c
+++ b/compat-wireless-2010-12-13/drivers/net/wireless/wl12xx/main.c
@@ -1858,11 +1858,17 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
{
enum wl1271_cmd_ps_mode mode;
struct wl1271 *wl = hw->priv;
- struct ieee80211_sta *sta = ieee80211_find_sta(vif, bss_conf->bssid);
+ rcu_read_lock();
+ struct ieee80211_sta *sta;
bool do_join = false;
bool set_assoc = false;
int ret;
+ sta = ieee80211_find_sta(vif, bss_conf->bssid);
+ if (!sta) {
+ rcu_read_unlock();
+ return;
+ }
wl1271_debug(DEBUG_MAC80211, "mac80211 bss info changed");
+ rcu_read_unlock();
mutex_lock(&wl->mutex);
--
Is this a known bug that has already been encountered? I am using the compat wireless flavor of the mac80211 framework and driver so I don't really know if you can come across this issue with standard kernel.
Thanks,
John
^ permalink raw reply related
* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: Bruno Randolf @ 2011-01-11 9:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, nbd, linux-wireless
In-Reply-To: <1294734744.3611.3.camel@jlt3.sipsolutions.net>
On Tue January 11 2011 17:32:24 Johannes Berg wrote:
> I've fixed it up, but two things: You should've lost the "original
> author" crap after you fixed up the git author field.
Sorry for that.
> Secondly,
>
> > + printf("\tchannel receive time:\t\t%llu ms\n",
> > +
> > (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX]));
>
> caused warnings:
> survey.c: In function ‘print_survey_handler’:
> survey.c:55: warning: format ‘%llu’ expects type ‘long long unsigned int’,
> but argument 2 has type ‘uint64_t’ survey.c:58: warning: format ‘%llu’
> expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
> survey.c:61: warning: format ‘%llu’ expects type ‘long long unsigned int’,
> but argument 2 has type ‘uint64_t’ survey.c:64: warning: format ‘%llu’
> expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
> survey.c:67: warning: format ‘%llu’ expects type ‘long long unsigned int’,
> but argument 2 has type ‘uint64_t’
>
>
> because uint64_t isn't guaranteed to be unsigned long long (in fact, it
> is unsigned long on many machines). Please look at the commit and check.
Looks good & compiles on my platforms (x86, mips).
Thanks,
bruno
^ permalink raw reply
* Re: [PATCH] cfg80211: Extend channel to frequency mapping for 802.11j
From: Bruno Randolf @ 2011-01-11 9:17 UTC (permalink / raw)
To: Brian Prodoehl
Cc: johannes, linville, linux-wireless, Dan Williams, libertas-dev,
Ivo van Doorn, Gertjan van Wingerde, users
In-Reply-To: <AANLkTimYjvJbm9DPPDWWCsD76_DnFcBG3a2Z_B8Mhpzm@mail.gmail.com>
On Sat January 8 2011 22:08:41 Brian Prodoehl wrote:
> I guess I saw what I wanted to see when I took a second look at the
> re-posted patch. Here are compile-fixes to all the affected drivers.
> The following drivers are affected: mwl8k, iwlwifi, iwmc3200wifi,
> libertas, rt2x00, wl1251 and wl12xx. So I guess these driver fixes
> need to be split into seven patches. I don't use any of these
> drivers, so I can't really vouch for if I'm pulling the band the
> correct way for each. I'm happy to split and submit, but I wouldn't
> mind another set of eyes on these changes.
Thanks! I would say these changes have to be merged with my patch, so it can
be applied without breaking git bisect for the affected drivers.
> compat-wireless-2011-01-07.orig/drivers/net/wireless/libertas/cfg.c 2011-0
> 1-07 15:03:59.000000000 -0500
> +++
> compat-wireless-2011-01-07/drivers/net/wireless/libertas/cfg.c 2011-01-08
> 07:51:23.947290769 -0500
> @@ -607,7 +607,8 @@
> /* No channel, no luck */
> if (chan_no != -1) {
> struct wiphy *wiphy = priv->wdev->wiphy;
> - int freq = ieee80211_channel_to_frequency(chan_no);
> + int freq = ieee80211_channel_to_frequency(chan_no,
> + chan_no <= 14 ? IEEE80211_BAND_2GHZ :
IEEE80211_BAND_5GHZ);
The whole point of having the band argument is to avoid this. We now have
overlapping channel numbers: channel 8 and 12 are defined in 5GHz as well as
in 2.4GHz (that is for 20MHz channel width, there are more for 10 and 5MHz
width, but we don't support that yet). The band has to come from the hardware
or driver configuration.
> @@ -1597,7 +1598,8 @@
> lbs_deb_enter(LBS_DEB_CFG80211);
>
> survey->channel = ieee80211_get_channel(wiphy,
> - ieee80211_channel_to_frequency(priv->channel));
> + ieee80211_channel_to_frequency(priv->channel,
> + priv->channel <= 14 ? IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ));
Same here.
> compat-wireless-2011-01-07.orig/drivers/net/wireless/rt2x00/rt2x00dev.c 20
> 11-01-07 15:03:59.000000000 -0500
> +++
> compat-wireless-2011-01-07/drivers/net/wireless/rt2x00/rt2x00dev.c
2011-01
> -08 07:51:23.971290769 -0500
> @@ -649,7 +649,8 @@
> const int channel, const int tx_power,
> const int value)
> {
> - entry->center_freq = ieee80211_channel_to_frequency(channel);
> + entry->center_freq = ieee80211_channel_to_frequency(channel,
> + channel <= 14 ? IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ);
And here.
So the two problematic drivers are libertas and rt2x00. I'm Cc'ing the
maintainers, and hope that they have better insight into how to fix this than
we.
bruno
^ permalink raw reply
* Re: [PATCH] wl12xx: reset 5ghz num channels on hw init
From: Luciano Coelho @ 2011-01-11 8:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <1294735015.3611.5.camel@jlt3.sipsolutions.net>
On Tue, 2011-01-11 at 09:36 +0100, Johannes Berg wrote:
> On Tue, 2011-01-11 at 10:32 +0200, Luciano Coelho wrote:
> > Hi Johannes,
> >
> > On Tue, 2011-01-11 at 09:25 +0100, Johannes Berg wrote:
> > > On Mon, 2011-01-10 at 23:04 +0200, Arik Nemtsov wrote:
> > > > The number of 5ghz channels is set to 0 when 11a is not supported in the
> > > > NVS file. When a single rmmod/insmod of wl12xx_sdio this leads to a
> > > > supported band (5ghz) with 0 supported channels, which mac80211
> > > > considers illegal.
> > >
> > > The setting to 0 shouldn't be happening in a global structure anyway
> > > since that way you can't support two different devices in the same
> > > system!!
> >
> > This is that hack we discussed some time ago on how to disable the 11a
> > channels. [snip explanation]
>
> You misunderstood: I do remember discussing the hack, and it's still a
> hack but it works and I'm OK with it. However, you shouldn't be
> modifying a _global_ struct. You should at least copy the sband struct
> itself (array actually then), which can still refer to the global
> channel array, but then you don't modify global shared data for
> device-dependent properties like this.
Right! Now I got it. Yeah, obviously the global shouldn't be modified,
otherwise all the registered hardwares will get their values modified at
the same time, which doesn't make sense. Well, apparently that was not
so obvious to me when I looked it at first. ;)
Thanks for your comment, I'll fix that.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: reset 5ghz num channels on hw init
From: Johannes Berg @ 2011-01-11 8:36 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <1294734738.12992.45.camel@pimenta>
On Tue, 2011-01-11 at 10:32 +0200, Luciano Coelho wrote:
> Hi Johannes,
>
> On Tue, 2011-01-11 at 09:25 +0100, Johannes Berg wrote:
> > On Mon, 2011-01-10 at 23:04 +0200, Arik Nemtsov wrote:
> > > The number of 5ghz channels is set to 0 when 11a is not supported in the
> > > NVS file. When a single rmmod/insmod of wl12xx_sdio this leads to a
> > > supported band (5ghz) with 0 supported channels, which mac80211
> > > considers illegal.
> >
> > The setting to 0 shouldn't be happening in a global structure anyway
> > since that way you can't support two different devices in the same
> > system!!
>
> This is that hack we discussed some time ago on how to disable the 11a
> channels. [snip explanation]
You misunderstood: I do remember discussing the hack, and it's still a
hack but it works and I'm OK with it. However, you shouldn't be
modifying a _global_ struct. You should at least copy the sband struct
itself (array actually then), which can still refer to the global
channel array, but then you don't modify global shared data for
device-dependent properties like this.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/4] iw: Add channel busy time to survey
From: Johannes Berg @ 2011-01-11 8:32 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, nbd, linux-wireless
In-Reply-To: <20110111005112.10231.46375.stgit@localhost6.localdomain6>
On Tue, 2011-01-11 at 09:51 +0900, Bruno Randolf wrote:
> From: Felix Fietkau <nbd@openwrt.org>
>
> Print channel busy time in survey dump.
>
> This patch comes from OpenWRT. Original author: Felix Fietkau.
> Fixed up for unsigned values.
I've fixed it up, but two things: You should've lost the "original
author" crap after you fixed up the git author field.
Secondly,
>
> + printf("\tchannel receive time:\t\t%llu ms\n",
> + (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX]));
caused warnings:
survey.c: In function ‘print_survey_handler’:
survey.c:55: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
survey.c:58: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
survey.c:61: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
survey.c:64: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
survey.c:67: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’
because uint64_t isn't guaranteed to be unsigned long long (in fact, it
is unsigned long on many machines). Please look at the commit and check.
johannes
^ permalink raw reply
* Re: [PATCH] wl12xx: reset 5ghz num channels on hw init
From: Luciano Coelho @ 2011-01-11 8:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: Arik Nemtsov, linux-wireless@vger.kernel.org
In-Reply-To: <1294734327.3611.1.camel@jlt3.sipsolutions.net>
Hi Johannes,
On Tue, 2011-01-11 at 09:25 +0100, Johannes Berg wrote:
> On Mon, 2011-01-10 at 23:04 +0200, Arik Nemtsov wrote:
> > The number of 5ghz channels is set to 0 when 11a is not supported in the
> > NVS file. When a single rmmod/insmod of wl12xx_sdio this leads to a
> > supported band (5ghz) with 0 supported channels, which mac80211
> > considers illegal.
>
> The setting to 0 shouldn't be happening in a global structure anyway
> since that way you can't support two different devices in the same
> system!!
This is that hack we discussed some time ago on how to disable the 11a
channels. We only know that they're not supported after the driver is
loaded and the supported channels are already registered. We get the
info that the 11a are not supported in the calibration data that we
receive later.
See commit fb6a6819fad0d71b47577a51709440a9f8441f0a.
Earlier I was disabling the channels by setting the DISABLED flag, but
that was bad, because I was touching regulatory stuff and it was causing
other problems.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: reset 5ghz num channels on hw init
From: Johannes Berg @ 2011-01-11 8:25 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <1294693444-30807-1-git-send-email-arik@wizery.com>
On Mon, 2011-01-10 at 23:04 +0200, Arik Nemtsov wrote:
> The number of 5ghz channels is set to 0 when 11a is not supported in the
> NVS file. When a single rmmod/insmod of wl12xx_sdio this leads to a
> supported band (5ghz) with 0 supported channels, which mac80211
> considers illegal.
The setting to 0 shouldn't be happening in a global structure anyway
since that way you can't support two different devices in the same
system!!
johannes
^ permalink raw reply
* [PATCH] ath5k: Fix return codes for eeprom read functions.
From: Wojciech Dubowik @ 2011-01-11 8:00 UTC (permalink / raw)
To: linville; +Cc: Dr. David Alan Gilbert, linux-wireless, ath5k-devel, nbd
In-Reply-To: <14218728.3.1294732508485.JavaMail.wlan@CHBU500181>
Eeprom read functions are of bool type and not int.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
---
drivers/net/wireless/ath/ath5k/ahb.c | 7 ++++---
drivers/net/wireless/ath/ath5k/eeprom.c | 24 ++++++++----------------
drivers/net/wireless/ath/ath5k/eeprom.h | 5 ++---
drivers/net/wireless/ath/ath5k/pci.c | 9 +++++----
4 files changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
index 707cde1..ae84b86 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -31,7 +31,8 @@ static void ath5k_ahb_read_cachesize(struct ath_common *common, int *csz)
*csz = L1_CACHE_BYTES >> 2;
}
-bool ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
+static bool
+ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
{
struct ath5k_softc *sc = common->priv;
struct platform_device *pdev = to_platform_device(sc->dev);
@@ -46,10 +47,10 @@ bool ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
eeprom += off;
if (eeprom > eeprom_end)
- return -EINVAL;
+ return false;
*data = *eeprom;
- return 0;
+ return true;
}
int ath5k_hw_read_srev(struct ath5k_hw *ah)
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.c b/drivers/net/wireless/ath/ath5k/eeprom.c
index 80e6256..b6561f7 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath/ath5k/eeprom.c
@@ -72,7 +72,6 @@ static int
ath5k_eeprom_init_header(struct ath5k_hw *ah)
{
struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
- int ret;
u16 val;
u32 cksum, offset, eep_max = AR5K_EEPROM_INFO_MAX;
@@ -192,7 +191,7 @@ static int ath5k_eeprom_read_ants(struct ath5k_hw *ah, u32 *offset,
struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
u32 o = *offset;
u16 val;
- int ret, i = 0;
+ int i = 0;
AR5K_EEPROM_READ(o++, val);
ee->ee_switch_settling[mode] = (val >> 8) & 0x7f;
@@ -252,7 +251,6 @@ static int ath5k_eeprom_read_modes(struct ath5k_hw *ah, u32 *offset,
struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
u32 o = *offset;
u16 val;
- int ret;
ee->ee_n_piers[mode] = 0;
AR5K_EEPROM_READ(o++, val);
@@ -515,7 +513,6 @@ ath5k_eeprom_read_freq_list(struct ath5k_hw *ah, int *offset, int max,
int o = *offset;
int i = 0;
u8 freq1, freq2;
- int ret;
u16 val;
ee->ee_n_piers[mode] = 0;
@@ -551,7 +548,7 @@ ath5k_eeprom_init_11a_pcal_freq(struct ath5k_hw *ah, int offset)
{
struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
struct ath5k_chan_pcal_info *pcal = ee->ee_pwr_cal_a;
- int i, ret;
+ int i;
u16 val;
u8 mask;
@@ -970,7 +967,6 @@ ath5k_eeprom_read_pcal_info_5112(struct ath5k_hw *ah, int mode)
u32 offset;
u8 i, c;
u16 val;
- int ret;
u8 pd_gains = 0;
/* Count how many curves we have and
@@ -1228,7 +1224,7 @@ ath5k_eeprom_read_pcal_info_2413(struct ath5k_hw *ah, int mode)
struct ath5k_chan_pcal_info *chinfo;
u8 *pdgain_idx = ee->ee_pdc_to_idx[mode];
u32 offset;
- int idx, i, ret;
+ int idx, i;
u16 val;
u8 pd_gains = 0;
@@ -1419,7 +1415,7 @@ ath5k_eeprom_read_target_rate_pwr_info(struct ath5k_hw *ah, unsigned int mode)
u8 *rate_target_pwr_num;
u32 offset;
u16 val;
- int ret, i;
+ int i;
offset = AR5K_EEPROM_TARGET_PWRSTART(ee->ee_misc1);
rate_target_pwr_num = &ee->ee_rate_target_pwr_num[mode];
@@ -1593,7 +1589,7 @@ ath5k_eeprom_read_ctl_info(struct ath5k_hw *ah)
struct ath5k_edge_power *rep;
unsigned int fmask, pmask;
unsigned int ctl_mode;
- int ret, i, j;
+ int i, j;
u32 offset;
u16 val;
@@ -1733,16 +1729,12 @@ int ath5k_eeprom_read_mac(struct ath5k_hw *ah, u8 *mac)
u8 mac_d[ETH_ALEN] = {};
u32 total, offset;
u16 data;
- int octet, ret;
+ int octet;
- ret = ath5k_hw_nvram_read(ah, 0x20, &data);
- if (ret)
- return ret;
+ AR5K_EEPROM_READ(0x20, data);
for (offset = 0x1f, octet = 0, total = 0; offset >= 0x1d; offset--) {
- ret = ath5k_hw_nvram_read(ah, offset, &data);
- if (ret)
- return ret;
+ AR5K_EEPROM_READ(offset, data);
total += data;
mac_d[octet + 1] = data & 0xff;
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.h b/drivers/net/wireless/ath/ath5k/eeprom.h
index 7c09e15..d46f105 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.h
+++ b/drivers/net/wireless/ath/ath5k/eeprom.h
@@ -241,9 +241,8 @@ enum ath5k_eeprom_freq_bands{
#define AR5K_SPUR_SYMBOL_WIDTH_TURBO_100Hz 6250
#define AR5K_EEPROM_READ(_o, _v) do { \
- ret = ath5k_hw_nvram_read(ah, (_o), &(_v)); \
- if (ret) \
- return ret; \
+ if (!ath5k_hw_nvram_read(ah, (_o), &(_v))) \
+ return -EIO; \
} while (0)
#define AR5K_EEPROM_READ_HDR(_o, _v) \
diff --git a/drivers/net/wireless/ath/ath5k/pci.c b/drivers/net/wireless/ath/ath5k/pci.c
index 7f8c5b0..66598a0 100644
--- a/drivers/net/wireless/ath/ath5k/pci.c
+++ b/drivers/net/wireless/ath/ath5k/pci.c
@@ -69,7 +69,8 @@ static void ath5k_pci_read_cachesize(struct ath_common *common, int *csz)
/*
* Read from eeprom
*/
-bool ath5k_pci_eeprom_read(struct ath_common *common, u32 offset, u16 *data)
+static bool
+ath5k_pci_eeprom_read(struct ath_common *common, u32 offset, u16 *data)
{
struct ath5k_hw *ah = (struct ath5k_hw *) common->ah;
u32 status, timeout;
@@ -90,15 +91,15 @@ bool ath5k_pci_eeprom_read(struct ath_common *common, u32 offset, u16 *data)
status = ath5k_hw_reg_read(ah, AR5K_EEPROM_STATUS);
if (status & AR5K_EEPROM_STAT_RDDONE) {
if (status & AR5K_EEPROM_STAT_RDERR)
- return -EIO;
+ return false;
*data = (u16)(ath5k_hw_reg_read(ah, AR5K_EEPROM_DATA) &
0xffff);
- return 0;
+ return true;
}
udelay(15);
}
- return -ETIMEDOUT;
+ return false;
}
int ath5k_hw_read_srev(struct ath5k_hw *ah)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v5 1/2] wl12xx: BA initiator support
From: Luciano Coelho @ 2011-01-11 8:04 UTC (permalink / raw)
To: Levi, Shahar; +Cc: linux-wireless@vger.kernel.org, Luciano Coelho
In-Reply-To: <AANLkTimpDo=0AcL5OdEjnpB8-_o7XBJ5QT-mE-FmfZo6@mail.gmail.com>
On Tue, 2011-01-11 at 01:18 +0100, Levi, Shahar wrote:
> On Tue, Jan 11, 2011 at 2:13 AM, Levi, Shahar <shahar_levi@ti.com> wrote:
> >
> > On Mon, Jan 10, 2011 at 5:00 PM, Luciano Coelho <coelho@ti.com> wrote:
> >>
> >> On Mon, 2011-01-03 at 14:42 +0100, Shahar Levi wrote:
> >> > diff --git a/drivers/net/wireless/wl12xx/acx.h b/drivers/net/wireless/wl12xx/acx.h
> >> > index 9cbc3f4..df48468 100644
> >> > --- a/drivers/net/wireless/wl12xx/acx.h
> >> > +++ b/drivers/net/wireless/wl12xx/acx.h
> >> > @@ -1051,6 +1051,40 @@ struct wl1271_acx_ht_information {
> >> > u8 padding[3];
> >> > } __packed;
> >> >
> >> > +#define BA_WIN_SIZE 8
> >>
> >> Should this be DEFAULT_BA_WIN_SIZE?
> >
> No, the FW support win size of 8. it is not configurable.
If only 8 is supported, why do we even have to pass it to the firmware
in the ACX_BA_SESSION_POLICY_CFG command? I think that, even though this
cannot be really changed, it should be part of the conf structure.
> >> > +{
> >> > + char fw_ver_str[ETHTOOL_BUSINFO_LEN];
> >>
> >> This is weird, but it seem to be what is used in cfg80211 (as Shahar
> >> pointed out on IRC). IMHO it should be ETHTOOL_FWVERS_LEN instead, both
> >> here and in cfg80211.
> >>
> >> In any case, this is a bit confusing here, because we don't use the
> >> fw_version in the wiphy struct (we probably should). Let's keep it like
> >> this for now and maybe later we can change.
> >>
> >> Also, I don't see why you need a local copy here.
> >
> i use local copy in order to remove '.' (*fw_ver_point = '\0') without
> destroyed wl->chip.fw_ver_str.
Ah, I see, but if you use sscanf, as I suggested, this won't be needed
anymore.
> >> > @@ -161,10 +166,13 @@ struct wl1271_partition_set {
> >> >
> >> > struct wl1271;
> >> >
> >> > +#define WL12XX_NUM_FW_VER 5
> >> > +
> >>
> >> WL12XX_FW_VER_OFFSET sounds better to me.
> >>
> >> And it shouldn't it be 4,
> >> which is the "Rev " prefix?
> >
> the macro represent the number of numbers in the version. it is not offset.
Right, I guess I didn't follow your algorithm in details, since using
sscanf would be much easier.
--
Cheers,
Luca.
^ permalink raw reply
* Re: What pieces are needed for wl1271..what directories, files, configs, etc..
From: Krakowski, Oz @ 2011-01-11 6:13 UTC (permalink / raw)
To: Brzezowski, Karen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <0826983CC0CB074798C42E77D8ACD07F067DE7@pdtms1.pdt.com>
Hi Karen,
On Mon, Jan 10, 2011 at 10:44 AM, Brzezowski, Karen
<Karen.Brzezowski@pdt.com> wrote:
>
> Hello all wireless gurus!!
>
> I've been watching the linux-wireless mailings on the wl1271...........
>
> I've been trying to figure out how to get the wl1271 working with
> imx233 processor...
>
> I think we are moving to Linux 2.6.35 and android gingerbread (2.3)...
>
> I"m very confused as to what files/configs/etc..need to be grabbed to get my task going.......
>
> I see spi, sdio...not sure where all changes are made for the wl1271...i'm assuming
> not just in the ...net/wireless/wl1271 directory.......... i have firmware too...........(.bins..)
>
> I'm quite confused about the chip and how each part will work (BT, WLAN, and FM)...
> Do you have any documentation..(for dummies, that would be me!)
> that would help me understand about the chip..how it communicates to the processor,
> how it does it's job with respect to BT, WLAN, and FM, etc..
>
> I have NO idea where to begin.......I've been googling and reading and I have downloaded
> your wl12xx git........
If you haven't done so already, suggest you start by going through the
following wiki page: http://linuxwireless.org/en/users/Drivers/wl12xx
This should give you an idea of where to get the latest code, how to
compile it to your kernel (using compat-wireless) and links to the
relevant patches needed.
This will get you started with WLAN.
>
> If you can help me AT ALL to get me up to speed/ to start, what i need to do to connect
> the wl1271 to the imx233....if not imx233..that whatever you have........
The wiki page does include some basic information needed in order to
port to different hardware platforms.
Regards,
Oz.
^ permalink raw reply
* Re: [PATCH 1/4] ath9k: fix bogus sequence number increases on aggregation tid flush
From: Ben Greear @ 2011-01-11 4:39 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1294704350-50621-1-git-send-email-nbd@openwrt.org>
On 01/10/2011 04:05 PM, Felix Fietkau wrote:
> When a tid pointer is passed to ath_tx_send_normal(), it increases the
> starting sequence number for the next AMPDU action frame, which should
> only be done if the sequence number assignment is fresh. In this case
> it is clearly not.
I added these to my system. It doesn't seem any worse, but I'm
still seeing my tx-hang logic kick off, so at least some of the
pending queue stuff still has issues I think:
ath: txq: ec731e78 axq_qnum: 2, mac80211_qnum: 2 axq_link: (null) pending frames: 73 axq_acq empty: 0 stopped: 0 axq_depth: 0 Attempting to restart tx logic.
In general though, my testing is finally starting to surprise with good results
instead of bugs, so I'm quite optimistic these days!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v3 2/2] wl12xx: BA receiver support
From: Levi, Shahar @ 2011-01-11 0:54 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1294674256.1992.141.camel@pimenta>
On Mon, Jan 10, 2011 at 5:44 PM, Luciano Coelho <coelho@ti.com> wrote:
> On Mon, 2011-01-03 at 14:42 +0100, Shahar Levi wrote:
>> Add new ampdu_action ops to support receiver BA.
>> The BA initiator session management in FW independently.
>>
>> Signed-off-by: Shahar Levi <shahar_levi@ti.com>
>> ---
>
> Some comments.
Thanks for your review.
>
>
>
>> diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
>> index 54fd68d..f33ab50 100644
>> --- a/drivers/net/wireless/wl12xx/acx.c
>> +++ b/drivers/net/wireless/wl12xx/acx.c
>> @@ -1359,6 +1359,42 @@ out:
>> return ret;
>> }
>>
>> +/* setup BA session receiver setting in the FW. */
>> +int wl1271_acx_set_ba_receiver_session(struct wl1271 *wl, u8 tid_index,
>> + u16 *ssn, u8 policy)
>
> You don't modify ssn here, so why pass it as a pointer? Use u16 directly
> here instead.
>
> Actually it's even worse. As stated in mac80211.h, ssn can be NULL
> here, so you would be accessing a NULL pointer in that case.
>
> I see that you check "policy", which indicates whether ssn is valid or
> not, but why not make it cleaner by checking if ssn is NULL and setting
> it to zero before passing instead?
good chtch. it was left from previous implantation. will be fix.
>
>
>> + acx->enable = policy;
>
> Also, because of this, it would make more sense if policy was a boolean
> and was called "enable" instead.
np, will be fix
>
>
>> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
>> index c44462d..04b69ab 100644
>> --- a/drivers/net/wireless/wl12xx/main.c
>> +++ b/drivers/net/wireless/wl12xx/main.c
>> @@ -2251,6 +2251,64 @@ static int wl1271_op_get_survey(struct ieee80211_hw *hw, int idx,
>> return 0;
>> }
>>
>> +int wl1271_op_ampdu_action(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
>> + enum ieee80211_ampdu_mlme_action action,
>> + struct ieee80211_sta *sta, u16 tid, u16 *ssn)
>> +{
>> + struct wl1271 *wl = hw->priv;
>> + int ret;
>> +
>> + mutex_lock(&wl->mutex);
>> +
>> + if (unlikely(wl->state == WL1271_STATE_OFF)) {
>> + ret = -EAGAIN;
>> + goto out;
>> + }
>> +
>> + ret = wl1271_ps_elp_wakeup(wl, false);
>> + if (ret < 0)
>> + goto out;
>> +
>> + switch (action) {
>> + case IEEE80211_AMPDU_RX_START:
>> + if ((wl->ba_allowed) && (wl->ba_support)) {
>
> I'm a bit confused. What is ba_allowed, actually? In the previous patch
> you always call wl1271_set_ba_policies() which always sets it to true.
> So it seems quite useless.
ba_allowed belong to next path "Stop BA session event from device". i
will move it.
>
>
>> + ret = wl1271_acx_set_ba_receiver_session(wl, tid, ssn,
>> + true);
>> + if (!ret)
>> + wl->ba_rx_bitmap |= BIT(tid);
>> + } else
>> + ret = -EPERM;
>
> The indentation is wrong here. And -EPERM is definitely not the right
> return code for this. It should probably -ENOTSUPP or something like
> that.
any error will be good. i go on "Operation not permitted". will be fix.
>
>> + /*
>> + * The BA initiator session management in FW independently.
>> + * Falling break here on purpose for all TX APDU commands.
>> + */
>> + case IEEE80211_AMPDU_TX_START:
>> + case IEEE80211_AMPDU_TX_STOP:
>> + case IEEE80211_AMPDU_TX_OPERATIONAL:
>> + ret = -EINVAL;
>> + break;
>
> -EINVAL? Actually, should mac80211 even call us with these actions? I
> don't remember now, did you implement the way to prevent mac80211 from
> trying to to AMPDU_TX by itself?
the mac souldn't call those due to the fact the rate management is in the FW.
>
>
>> +
>> + default:
>> + wl1271_error("Incorrect ampdu action id=%x\n", action);
>> + ret = -ENODEV;
>
> -ENODEV? All these error codes look quite random to me. Can you explain
> your choices?
amm, i am trying to remeber why i use that one without success. i will
switch it to EINVAL.
>
>
> --
> Cheers,
> Luca.
Shahar
^ permalink raw reply
* [PATCH v2 4/4] iw: Add signal average to station dump information
From: Bruno Randolf @ 2011-01-11 0:51 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
In-Reply-To: <20110111005107.10231.81618.stgit@localhost6.localdomain6>
Print station signal average in station dump.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
station.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/station.c b/station.c
index be2301f..6581d50 100644
--- a/station.c
+++ b/station.c
@@ -107,6 +107,9 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
if (sinfo[NL80211_STA_INFO_SIGNAL])
printf("\n\tsignal: \t%d dBm",
(int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL]));
+ if (sinfo[NL80211_STA_INFO_SIGNAL_AVG])
+ printf("\n\tsignal avg:\t%d dBm",
+ (int8_t)nla_get_u8(sinfo[NL80211_STA_INFO_SIGNAL_AVG]));
if (sinfo[NL80211_STA_INFO_TX_BITRATE]) {
if (nla_parse_nested(rinfo, NL80211_RATE_INFO_MAX,
^ permalink raw reply related
* [PATCH v2 3/4] iw: add multicast rates to IBSS join
From: Bruno Randolf @ 2011-01-11 0:51 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
In-Reply-To: <20110111005107.10231.81618.stgit@localhost6.localdomain6>
From: Felix Fietkau <nbd@openwrt.org>
Add multicast rates to IBSS join command.
This patch comes from OpenWRT. Original author: Felix Fietkau.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
ibss.c | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/ibss.c b/ibss.c
index 84ea7f2..ca8a4ec 100644
--- a/ibss.c
+++ b/ibss.c
@@ -95,6 +95,20 @@ static int join_ibss(struct nl80211_state *state,
argc--;
}
+ /* multicast rate */
+ if (argc > 1 && strcmp(argv[0], "mcast-rate") == 0) {
+ argv++;
+ argc--;
+
+ rate = strtod(argv[0], &end);
+ if (*end != '\0')
+ return 1;
+
+ NLA_PUT_U32(msg, NL80211_ATTR_MCAST_RATE, (int) rate * 10);
+ argv++;
+ argc--;
+ }
+
if (!argc)
return 0;
@@ -120,12 +134,13 @@ COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
COMMAND(ibss, join,
- "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [beacon-interval "
- "<TU>] [basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
+ "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [beacon-interval <TU>]"
+ " [basic-rates <rate in Mbps,rate2,...>] [mcast-rate <rate in Mbps>] "
+ "[key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
"join/create a cell on a different frequency. When a fixed BSSID is\n"
"requested use that BSSID and do not adopt another cell's BSSID even\n"
"if it has higher TSF and the same SSID. If an IBSS is created, create\n"
- "it with the specified basic-rates and beacon-interval (in TU).");
+ "it with the specified basic-rates, multicast-rate and beacon-interval.");
^ permalink raw reply related
* [PATCH v2 1/4] iw: survey: Mark frequency in use
From: Bruno Randolf @ 2011-01-11 0:51 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
From: Felix Fietkau <nbd@openwrt.org>
Survey: Mark frequency in use according to NL80211_SURVEY_INFO_IN_USE.
This patch comes from OpenWRT. Original author: Felix Fietkau
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
survey.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/survey.c b/survey.c
index f9f2508..83c54b3 100644
--- a/survey.c
+++ b/survey.c
@@ -44,8 +44,9 @@ static int print_survey_handler(struct nl_msg *msg, void *arg)
}
if (sinfo[NL80211_SURVEY_INFO_FREQUENCY])
- printf("\tfrequency:\t%u MHz\n",
- nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]));
+ printf("\tfrequency:\t%u MHz%s\n",
+ nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]),
+ sinfo[NL80211_SURVEY_INFO_IN_USE] ? " [in use]" : "");
if (sinfo[NL80211_SURVEY_INFO_NOISE])
printf("\tnoise:\t\t%d dBm\n",
(int8_t)nla_get_u8(sinfo[NL80211_SURVEY_INFO_NOISE]));
^ permalink raw reply related
* [PATCH v2 2/4] iw: Add channel busy time to survey
From: Bruno Randolf @ 2011-01-11 0:51 UTC (permalink / raw)
To: johannes, linville; +Cc: nbd, linux-wireless
In-Reply-To: <20110111005107.10231.81618.stgit@localhost6.localdomain6>
From: Felix Fietkau <nbd@openwrt.org>
Print channel busy time in survey dump.
This patch comes from OpenWRT. Original author: Felix Fietkau.
Fixed up for unsigned values.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
survey.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/survey.c b/survey.c
index 83c54b3..e71d21b 100644
--- a/survey.c
+++ b/survey.c
@@ -44,12 +44,27 @@ static int print_survey_handler(struct nl_msg *msg, void *arg)
}
if (sinfo[NL80211_SURVEY_INFO_FREQUENCY])
- printf("\tfrequency:\t%u MHz%s\n",
+ printf("\tfrequency:\t\t\t%u MHz%s\n",
nla_get_u32(sinfo[NL80211_SURVEY_INFO_FREQUENCY]),
sinfo[NL80211_SURVEY_INFO_IN_USE] ? " [in use]" : "");
if (sinfo[NL80211_SURVEY_INFO_NOISE])
- printf("\tnoise:\t\t%d dBm\n",
+ printf("\tnoise:\t\t\t\t%d dBm\n",
(int8_t)nla_get_u8(sinfo[NL80211_SURVEY_INFO_NOISE]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME])
+ printf("\tchannel active time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY])
+ printf("\tchannel busy time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_BUSY]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_EXT_BUSY])
+ printf("\textension channel busy time:\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_EXT_BUSY]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX])
+ printf("\tchannel receive time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_RX]));
+ if (sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_TX])
+ printf("\tchannel transmit time:\t\t%llu ms\n",
+ (uint64_t)nla_get_u64(sinfo[NL80211_SURVEY_INFO_CHANNEL_TIME_TX]));
return NL_SKIP;
}
^ permalink raw reply related
* Re: ath9k_hw_check_alive routine
From: Felix Fietkau @ 2011-01-11 0:26 UTC (permalink / raw)
To: Bill Jordan
Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian
In-Reply-To: <AANLkTikj+40TksokdnAKzXnBi7CBE5GO4BEKoaxQG79D@mail.gmail.com>
On 2011-01-10 1:23 PM, Bill Jordan wrote:
> This routine is failing a lot on my AR9160. The ((reg& 0x7E7FFFEF) ==
> 0x00702400) test is the one that always fails. There is no debug
> messages in this path, so it may not be obvious whether others are
> experiencing the problem.
>
> This forces ath9k_tasklet to reset the hardware. If I increase the
> count to 500, I can eliminate most of the resets, so the hardware
> isn't really hung. However, it sometimes takes over 25 milliseconds
> before the test condition passes.
>
> I don't have specs for the radio, and the numeric constants aren't
> very useful, so I can't tell what condition we are waiting for or why.
>
> Can someone with a spec shed some light on this problem?
I just posted a 4-patch series, the last patch of that should take care
of this problem. Please test.
- Felix
^ 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