* Re: [PATCH] rt28xx: Make PCI_{MAP,UNMAP}_SINGLE type-safe
From: drago01 @ 2010-04-28 18:19 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: ben, bzolnier, gregkh, linux-wireless, linux-kernel
In-Reply-To: <20100329110339P.fujita.tomonori@lab.ntt.co.jp>
On Mon, Mar 29, 2010 at 4:04 AM, FUJITA Tomonori
<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Mon, 29 Mar 2010 02:58:48 +0100
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
>> On Mon, 2010-03-29 at 10:52 +0900, FUJITA Tomonori wrote:
>> > On Mon, 29 Mar 2010 01:24:45 +0100
>> > Ben Hutchings <ben@decadent.org.uk> wrote:
>> >
>> > > To avoid recurrence of bugs such as <http://bugs.debian.org/575726>,
>> > > change the type of the first parameter to linux_pci_{map,unmap}_single()
>> > > from void * to struct rt_rtmp_adapter *. Also do not define the macros
>> > > PCI_{MAP,UNMAP}_SINGLE() when building the rt2870sta driver; they are
>> > > not used and if they were that would be a bug.
>> > >
>> > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> > > ---
>> > > drivers/staging/rt2860/rt_linux.h | 14 +++++---------
>> > > drivers/staging/rt2860/rt_pci_rbus.c | 12 ++++--------
>> > > 2 files changed, 9 insertions(+), 17 deletions(-)
>> >
>> > I think using dma_map_single directly instead of inventing a wrapper
>> > function make the code more readable.
>>
>> These functions are not quite simple wrappers, unfortunately. So while
>> I think that is worth doing it is a separate change.
>
> Well, the current wrapper functions looks terrible. Needs to fix them
> before moving the driver out of the staging anyway, I think.
The driver is not expected to make it ever out of staging ... unless
someone ports it to mac80211 ... the in kernel rt2x00 drivers are the
longer term solutions for supporting this hardware.
^ permalink raw reply
* Re: [PATCH] rt28xx: Make PCI_{MAP,UNMAP}_SINGLE type-safe
From: Greg KH @ 2010-04-28 17:39 UTC (permalink / raw)
To: Ben Hutchings
Cc: Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, linux-wireless,
LKML
In-Reply-To: <1269822285.8653.251.camel@localhost>
On Mon, Mar 29, 2010 at 01:24:45AM +0100, Ben Hutchings wrote:
> To avoid recurrence of bugs such as <http://bugs.debian.org/575726>,
> change the type of the first parameter to linux_pci_{map,unmap}_single()
> from void * to struct rt_rtmp_adapter *. Also do not define the macros
> PCI_{MAP,UNMAP}_SINGLE() when building the rt2870sta driver; they are
> not used and if they were that would be a bug.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
In the future, please do not sign your emails, it just makes it harder
to apply them :(
thanks,
greg k-h
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Antonio Quartulli @ 2010-04-28 17:23 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Luis Correia, linux-wireless, users
In-Reply-To: <201004281456.16600.helmut.schaa@googlemail.com>
On mer, apr 28, 2010 at 02:56:16 +0200, Helmut Schaa wrote:
> Am Mittwoch 28 April 2010 schrieb Antonio Quartulli:
> > On mar, apr 27, 2010 at 01:15:21 +0200, Antonio Quartulli wrote:
> > > On lun, apr 26, 2010 at 01:11:20 +0200, Helmut Schaa wrote:
> > > > Am Montag 26 April 2010 schrieb Helmut Schaa:
> > > > > Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> > > > > > rt2x00 had preliminary support for RT3070 based devices, but the support was
> > > > > > incomplete.
> > > > > > Update the RT3070 register initialization to be similar to the latest Ralink
> > > > > > vendor driver.
> > > > > >
> > > > > > With this patch my rt3070 based devices start showing a sign of life.
> > > > >
> > > > > Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
> > > > > more details.
> > > >
> > > > Antonio, did that patch also break rx on your PCI device with rt2872?
> > > > If not this is only needed for SoC.
> > > Hi, I cloned the wireless-testing git a few minutes ago.
> > > My card (rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003,
> > > rev: 0200) on miniPCI works correctly without any kind of problem.
> > > No hangs at all.
> >
> > Hi all, I found out that after this commit:
> >
> > commit 23812383c6b03afef44c4aa642500f8235c3d079
> > Author: Helmut Schaa <helmut.schaa@googlemail.com>
> > Date: Mon Apr 26 13:48:45 2010 +0200
> >
> > rt2x00: rt2800lib: Fix rx path on SoC devices
> >
> > my card becomes unstable, I mean that the connection lose packets and
> > sometimes it disassociates from the AP.
> > I also found that the singnal level reported by iwconfig is wrong (it
> > reports -191dBm)
>
> Uhhh, are you 100% sure? The patch doesn't touch any PCI code at all.
> Maybe the card was unstable before already? Could you please verify again?
>
> Thanks you very much for your testing, it's really appreciated.
>
I pull the latest commit on wireless-testing. Now it seems to work well.
I cannot understand what happened. Anyway the signal level is still
wrong because iwconfig shows a positive value instead of a negative one
(the absolute value seems plausible).
On 2.6.34-rc* kernel I still have the same issue I noticed some times
ago:
Apr 28 00:10:18 eagle3 kernel: [ 1359.907914] rt2800pci 0000:06:00.0: firmware: requesting rt2860.bin
Apr 28 00:10:18 eagle3 kernel: [ 1360.033584] phy1 -> rt2x00lib_request_firmware: Info - Firmware detected - version: 0.26.
Apr 28 00:10:18 eagle3 kernel: [ 1360.043280] phy1 -> rt2800pci_load_firmware: Error - PBF system register not ready.
Apr 28 00:10:18 eagle3 kernel: [ 1360.043793] phy1 -> rt2x00pci_regbusy_read: Error - Indirect register access failed:
offset=0x00007010, value=0x3dca191a
Regards
--
Antonio Quartulli
Ognuno di noi, da solo, non vale nulla
Ernesto "Che" Guevara
^ permalink raw reply
* Re: [RFT] ar9170: implement get_survey
From: Christian Lamparter @ 2010-04-28 15:56 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
In-Reply-To: <4BD76360.2070005@free.fr>
On Wednesday 28 April 2010 00:21:20 Benoit PAPILLAULT wrote:
> Christian Lamparter a écrit :
> > This patch adds a basic get_survey for ar9170.
> >
> > Survey data from wlan1
> > frequency: 2412 MHz
> > noise: -85 dBm
> >
> > TODO:
> > Currently, the noise level is updated only by a channel change.
> > Now, we could simply add another ar9170_set_channel to always get
> > a fresh result, but then we risk a RF lockup.
> >
> It seems to be a good start. The code is very similar to what is used in
> ath9k. Just few questions below.
Naaa, If it was, It would have started with [PATCH] :-D
As you pointed out at the end, there is still some important
work left on the TODO.
> > ---
> > diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c
> > index 45a415e..31ff163 100644
> > --- a/drivers/net/wireless/ath/ar9170/phy.c
> > +++ b/drivers/net/wireless/ath/ar9170/phy.c
> > @@ -1584,6 +1584,31 @@ static int ar9170_calc_noise_dbm(u32 raw_noise)
> > return (raw_noise & 0xff) >> 1;
> > }
> >
> > +int ar9170_get_noisefloor(struct ar9170 *ar)
> > +{
> > + static const u32 phy_regs[] = {
> > + 0x1c5864, 0x1c6864, 0x1c7864,
> > + 0x1c59bc, 0x1c69bc, 0x1c79bc };
> >
> Maybe #define would be more appropriate. Moreover, it's clear in my
> notes that some ar9170 registers are just ath9k registers + 0x1bc000.
I several files full of #defines for the RF,BB and MAC (and USB) in carl9170.
But I don't want to do mix those, because not all registers in those
files have been verified & tested yet.
So I copied the magics values from the original firmware...
> > + u32 phy_res[ARRAY_SIZE(phy_regs)];
> > + int err, i;
> > +
> > + BUILD_BUG_ON(ARRAY_SIZE(phy_regs) != ARRAY_SIZE(ar->noise));
> > +
> > + err = ar9170_read_mreg(ar, ARRAY_SIZE(phy_regs), phy_regs, phy_res);
> > + if (err)
> > + return err;
> > +
> > + for (i = 0; i < ARRAY_SIZE(phy_regs); i++) {
> > + ar->noise[i] = ar9170_calc_noise_dbm(
> > + (phy_res[i] >> 19) & 0x1ff);
> > +
> > + ar->noise[i + 3] = ar9170_calc_noise_dbm(
> > + (phy_res[i + 3] >> 23) & 0x1ff);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > int ar9170_set_channel(struct ar9170 *ar, struct ieee80211_channel *channel,
> > enum ar9170_rf_init_mode rfi, enum ar9170_bw bw)
> > {
> > @@ -1708,12 +1733,12 @@ int ar9170_set_channel(struct ar9170 *ar, struct ieee80211_channel *channel,
> > }
> > }
> >
> > - for (i = 0; i < 2; i++) {
> > + for (i = 0; i < 3; i++) {
> >
> Why using 3 RX channels ? ar9170 is always 2x2, isn't it ? And why read
> 3 values since only one will be used in ar9170_op_get_survey?
ah, I think that's because the first CCA & EXT_CCA values are the
combinded result of both chains (might have something to do with
Smart Antenna and Maximal Ratio Combining techniques, whoever
I can't give you any reference for that, simply because most
of the papers I have are from Atheros' marketing department ;-) )
Also, this is not a hot path. We can easily save all calibration
results and make them accessible through the debug interface together
with other phy/rf related variables (e.g.: mib counters and ani registers)
> Maybe we should combine the 3 values before reporting a single value ?
> > ar->noise[i] = ar9170_calc_noise_dbm(
> > - (le32_to_cpu(vals[2 + i]) >> 19) & 0x1ff);
> > + (le32_to_cpu(vals[i + 1]) >> 19) & 0x1ff);
> >
> > - ar->noise[i + 2] = ar9170_calc_noise_dbm(
> > - (le32_to_cpu(vals[5 + i]) >> 23) & 0x1ff);
> > + ar->noise[i + 3] = ar9170_calc_noise_dbm(
> > + (le32_to_cpu(vals[i + 4]) >> 23) & 0x1ff);
> > }
> >
> > ar->channel = channel;
> >
> Moreover (but my patch for ath9k has the very same error), I think we
> are reported the noise floor calibration result which is not the noise
> at all... that might be another story anyway.
True, but hey we've reported these noise figures for a very long time now
and no one complained, so the delta can't be that important in RL :-D.
Of course we could also initiate another NF calibration right here,
but due to the number of people reporting PHY problems with ar9170,
I'm somewhat nervous about that.
Regards,
Chr
^ permalink raw reply
* [PATCH] mac80211: notify driver about IBSS status
From: Johannes Berg @ 2010-04-28 15:40 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
Some drivers (e.g. iwlwifi) need to know and try
to figure it out based on other things, but making
it explicit is definitely better.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Yay. cfg80211 really made things easy. Not a billion of code paths to go
through for ifdown and all that :)
include/net/mac80211.h | 6 +++++-
net/mac80211/ibss.c | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -145,6 +145,7 @@ struct ieee80211_low_level_stats {
* @BSS_CHANGED_BEACON_ENABLED: Beaconing should be
* enabled/disabled (beaconing modes)
* @BSS_CHANGED_CQM: Connection quality monitor config changed
+ * @BSS_CHANGED_IBSS: IBSS join status changed
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -158,6 +159,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_BEACON = 1<<8,
BSS_CHANGED_BEACON_ENABLED = 1<<9,
BSS_CHANGED_CQM = 1<<10,
+ BSS_CHANGED_IBSS = 1<<11,
};
/**
@@ -167,6 +169,8 @@ enum ieee80211_bss_change {
* to that BSS) that can change during the lifetime of the BSS.
*
* @assoc: association status
+ * @ibss_joined: indicates whether this station is part of an IBSS
+ * or not
* @aid: association ID number, valid only when @assoc is true
* @use_cts_prot: use CTS protection
* @use_short_preamble: use 802.11b short preamble;
@@ -194,7 +198,7 @@ enum ieee80211_bss_change {
struct ieee80211_bss_conf {
const u8 *bssid;
/* association related data */
- bool assoc;
+ bool assoc, ibss_joined;
u16 aid;
/* erp related data */
bool use_cts_prot;
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index e6f3b0c..e47ad17 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -171,6 +171,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
bss_change |= BSS_CHANGED_BSSID;
bss_change |= BSS_CHANGED_BEACON;
bss_change |= BSS_CHANGED_BEACON_ENABLED;
+ bss_change |= BSS_CHANGED_IBSS;
+ sdata->vif.bss_conf.ibss_joined = true;
ieee80211_bss_info_change_notify(sdata, bss_change);
ieee80211_sta_def_wmm_params(sdata, sband->n_bitrates, supp_rates);
@@ -951,7 +953,9 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
kfree(sdata->u.ibss.ie);
skb = sdata->u.ibss.presp;
rcu_assign_pointer(sdata->u.ibss.presp, NULL);
- ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+ sdata->vif.bss_conf.ibss_joined = false;
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
+ BSS_CHANGED_IBSS);
synchronize_rcu();
kfree_skb(skb);
^ permalink raw reply related
* [PATCH 2/2 v2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Stanislaw Gruszka @ 2010-04-28 15:03 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Johannes Berg
In-Reply-To: <1272463157.3565.22.camel@jlt3.sipsolutions.net>
If AP do not provide us supported rates before assiociation, send
all rates we are supporting instead of empty information element.
v1 -> v2: Add comment.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
net/mac80211/work.c | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index 15e1ba9..949c2d1 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -213,15 +213,25 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
sband = local->hw.wiphy->bands[wk->chan->band];
- /*
- * Get all rates supported by the device and the AP as
- * some APs don't like getting a superset of their rates
- * in the association request (e.g. D-Link DAP 1353 in
- * b-only mode)...
- */
- rates_len = ieee80211_compatible_rates(wk->assoc.supp_rates,
- wk->assoc.supp_rates_len,
- sband, &rates);
+ if (wk->assoc.supp_rates_len) {
+ /*
+ * Get all rates supported by the device and the AP as
+ * some APs don't like getting a superset of their rates
+ * in the association request (e.g. D-Link DAP 1353 in
+ * b-only mode)...
+ */
+ rates_len = ieee80211_compatible_rates(wk->assoc.supp_rates,
+ wk->assoc.supp_rates_len,
+ sband, &rates);
+ } else {
+ /*
+ * In case AP not provide any supported rates information
+ * before association, we send information element(s) with
+ * all rates that we support.
+ */
+ rates = ~0;
+ rates_len = sband->n_bitrates;
+ }
skb = alloc_skb(local->hw.extra_tx_headroom +
sizeof(*mgmt) + /* bit too much but doesn't matter */
--
1.6.2.5
^ permalink raw reply related
* Re: kernel warning on 2.6.33 ath9k
From: John W. Linville @ 2010-04-28 14:04 UTC (permalink / raw)
To: Xu, Martin; +Cc: ath9k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org
In-Reply-To: <FC2FB65B4D919844ADE4BE3C2BB739AD1E4FB31B@shsmsx501.ccr.corp.intel.com>
On Wed, Apr 28, 2010 at 04:01:45PM +0800, Xu, Martin wrote:
> Hi
> I found that kernel reports below warning when using ath9k in kernel 2.6.33.
> Someone can kindly tell me whether it is the new found issue or the issue is known and has been fixed in later commit in git tree?
> Thanks!
Looks like this:
https://bugzilla.kernel.org/show_bug.cgi?id=15839
> ------------[ cut here ]------------
> WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x32/0x76()
> Hardware name: AO532h
> Modules linked in: cbc ecryptfs ath9k ath9k_common battery atl1c joydev ath9k_hw uvcvideo
> Pid: 850, comm: wpa_supplicant Not tainted 2.6.33.2-8.1-netbook #1
> Call Trace:
> [<c1030978>] warn_slowpath_common+0x66/0x7d
> [<c1035a74>] ? local_bh_enable_ip+0x32/0x76
> [<c103099c>] warn_slowpath_null+0xd/0x10
> [<c1035a74>] local_bh_enable_ip+0x32/0x76
> [<c14789c0>] _raw_spin_unlock_bh+0x17/0x19
> [<f871dbd3>] ath_tx_node_cleanup+0xe0/0xf9 [ath9k]
> [<c103ae46>] ? lock_timer_base+0x22/0x41
> [<f871a005>] ath9k_sta_notify+0x74/0x78 [ath9k]
> [<c1443987>] __sta_info_unlink+0x139/0x189
> [<f8719f91>] ? ath9k_sta_notify+0x0/0x78 [ath9k]
> [<c14439fa>] sta_info_unlink+0x23/0x31
> [<c1448834>] ieee80211_set_disassoc+0x1bd/0x1e3
> [<c1448cf8>] ieee80211_mgd_deauth+0x3c/0xfe
> [<c144df21>] ieee80211_deauth+0x14/0x16
> [<c143c3fc>] __cfg80211_mlme_deauth+0xe9/0xf2
> [<c143eea1>] __cfg80211_disconnect+0xcb/0x12e
> [<c1440b74>] cfg80211_wext_siwmlme+0x64/0x80
> [<c1441cf6>] ioctl_standard_call+0x1d7/0x26f
> [<c139281b>] ? dev_get_by_name_rcu+0x73/0x80
> [<c13928d9>] ? __dev_get_by_name+0x71/0x7e
> [<c1441e81>] wext_handle_ioctl+0xf3/0x17e
> [<c1440b10>] ? cfg80211_wext_siwmlme+0x0/0x80
> [<c1396410>] dev_ioctl+0x578/0x598
> [<c10091b9>] ? restore_i387_fxsave+0x54/0x66
> [<c1387b44>] sock_ioctl+0x1cf/0x1db
> [<c10b0979>] vfs_ioctl+0x28/0x92
> [<c1387975>] ? sock_ioctl+0x0/0x1db
> [<c10b0ed6>] do_vfs_ioctl+0x453/0x491
> [<c1388233>] ? sys_recvmsg+0x2c/0x47
> [<c1389542>] ? sys_socketcall+0x147/0x18c
> [<c10b0f43>] sys_ioctl+0x2f/0x49
> [<c10027d0>] sysenter_do_call+0x12/0x26
--
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: [PATCH 2/2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Johannes Berg @ 2010-04-28 13:59 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20100428155755.75f1dc5a@dhcp-lab-109.englab.brq.redhat.com>
On Wed, 2010-04-28 at 15:57 +0200, Stanislaw Gruszka wrote:
> On Wed, 28 Apr 2010 15:39:24 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > Could you add a comment about what AP this is
>
> Bug reporter don't know what AP it is. He fail to connect
> to wireless network at school.
> https://bugzilla.redhat.com/show_bug.cgi?id=558002
Ah bugger.
> >, and that it's a
> > workaround please?
>
> I don't think this is workaround. For me this is right behavior
> and fix for workaround introduced in commit
> 36d16ae73becc5978fe22866e9ab66b509211afe "mac80211: fix association
> with some APs"
Oh yeah so it's a workaround for a workaround. Oh well. Can we still
have a comment about it in the else branch?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Stanislaw Gruszka @ 2010-04-28 13:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John W. Linville
In-Reply-To: <1272461964.3565.21.camel@jlt3.sipsolutions.net>
On Wed, 28 Apr 2010 15:39:24 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> Could you add a comment about what AP this is
Bug reporter don't know what AP it is. He fail to connect
to wireless network at school.
https://bugzilla.redhat.com/show_bug.cgi?id=558002
>, and that it's a
> workaround please?
I don't think this is workaround. For me this is right behavior
and fix for workaround introduced in commit
36d16ae73becc5978fe22866e9ab66b509211afe "mac80211: fix association
with some APs"
> The AP is surely supposed to send this information!
The same as we are, no matter what :-)
Cheers
Stanislaw
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Johannes Berg @ 2010-04-28 13:39 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, John W. Linville
In-Reply-To: <1272460624-3611-2-git-send-email-sgruszka@redhat.com>
On Wed, 2010-04-28 at 15:17 +0200, Stanislaw Gruszka wrote:
> If AP do not provide us supported rates before assiociation, send
> all rates we are supporting instead of empty information element.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> net/mac80211/work.c | 23 ++++++++++++++---------
> 1 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/net/mac80211/work.c b/net/mac80211/work.c
> index 15e1ba9..f8f5c9a 100644
> --- a/net/mac80211/work.c
> +++ b/net/mac80211/work.c
> @@ -213,15 +213,20 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
>
> sband = local->hw.wiphy->bands[wk->chan->band];
>
> - /*
> - * Get all rates supported by the device and the AP as
> - * some APs don't like getting a superset of their rates
> - * in the association request (e.g. D-Link DAP 1353 in
> - * b-only mode)...
> - */
> - rates_len = ieee80211_compatible_rates(wk->assoc.supp_rates,
> - wk->assoc.supp_rates_len,
> - sband, &rates);
> + if (wk->assoc.supp_rates_len) {
> + /*
> + * Get all rates supported by the device and the AP as
> + * some APs don't like getting a superset of their rates
> + * in the association request (e.g. D-Link DAP 1353 in
> + * b-only mode)...
> + */
> + rates_len = ieee80211_compatible_rates(wk->assoc.supp_rates,
> + wk->assoc.supp_rates_len,
> + sband, &rates);
> + } else {
> + rates = ~0;
> + rates_len = sband->n_bitrates;
> + }
Could you add a comment about what AP this is, and that it's a
workaround please? The AP is surely supposed to send this information!
johannes
^ permalink raw reply
* [PATCH 2/2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Stanislaw Gruszka @ 2010-04-28 13:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville, Stanislaw Gruszka
In-Reply-To: <1272460624-3611-1-git-send-email-sgruszka@redhat.com>
If AP do not provide us supported rates before assiociation, send
all rates we are supporting instead of empty information element.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
net/mac80211/work.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index 15e1ba9..f8f5c9a 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -213,15 +213,20 @@ static void ieee80211_send_assoc(struct ieee80211_sub_if_data *sdata,
sband = local->hw.wiphy->bands[wk->chan->band];
- /*
- * Get all rates supported by the device and the AP as
- * some APs don't like getting a superset of their rates
- * in the association request (e.g. D-Link DAP 1353 in
- * b-only mode)...
- */
- rates_len = ieee80211_compatible_rates(wk->assoc.supp_rates,
- wk->assoc.supp_rates_len,
- sband, &rates);
+ if (wk->assoc.supp_rates_len) {
+ /*
+ * Get all rates supported by the device and the AP as
+ * some APs don't like getting a superset of their rates
+ * in the association request (e.g. D-Link DAP 1353 in
+ * b-only mode)...
+ */
+ rates_len = ieee80211_compatible_rates(wk->assoc.supp_rates,
+ wk->assoc.supp_rates_len,
+ sband, &rates);
+ } else {
+ rates = ~0;
+ rates_len = sband->n_bitrates;
+ }
skb = alloc_skb(local->hw.extra_tx_headroom +
sizeof(*mgmt) + /* bit too much but doesn't matter */
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 2/2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: Stanislaw Gruszka @ 2010-04-28 13:33 UTC (permalink / raw)
To: John W. Linville; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1272460624-3611-2-git-send-email-sgruszka@redhat.com>
On Wed, Apr 28, 2010 at 03:17:04PM +0200, Stanislaw Gruszka wrote:
> If AP do not provide us supported rates before assiociation, send
> all rates we are supporting instead of empty information element.
Please note these two patches together with "QoS fixes":
- mac80211: explicitly disable/enable QoS
- iwlwifi: manage QoS by mac stack
resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=558002
"QoS fixes" alone resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=539878
So I think we want all 4 patches in stable.
John,if possible push patches to Linus tree. When they lend there,
I will post backported patches to stable ML. I have them already
prepared ant tested for 2.6.32 :)
Thanks
Stanislaw
^ permalink raw reply
* [PATCH 1/2] mac80211: do not wip out old supported rates
From: Stanislaw Gruszka @ 2010-04-28 13:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, John W. Linville, Stanislaw Gruszka
Use old supported rates, if AP do not provide supported rates
information element in a new managment frame.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
net/mac80211/scan.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 85507bd..151d933 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -83,7 +83,7 @@ ieee80211_bss_info_update(struct ieee80211_local *local,
{
struct cfg80211_bss *cbss;
struct ieee80211_bss *bss;
- int clen;
+ int clen, srlen;
s32 signal = 0;
if (local->hw.flags & IEEE80211_HW_SIGNAL_DBM)
@@ -112,23 +112,24 @@ ieee80211_bss_info_update(struct ieee80211_local *local,
bss->dtim_period = tim_ie->dtim_period;
}
- bss->supp_rates_len = 0;
+ /* replace old supported rates if we get new values */
+ srlen = 0;
if (elems->supp_rates) {
- clen = IEEE80211_MAX_SUPP_RATES - bss->supp_rates_len;
+ clen = IEEE80211_MAX_SUPP_RATES;
if (clen > elems->supp_rates_len)
clen = elems->supp_rates_len;
- memcpy(&bss->supp_rates[bss->supp_rates_len], elems->supp_rates,
- clen);
- bss->supp_rates_len += clen;
+ memcpy(bss->supp_rates, elems->supp_rates, clen);
+ srlen += clen;
}
if (elems->ext_supp_rates) {
- clen = IEEE80211_MAX_SUPP_RATES - bss->supp_rates_len;
+ clen = IEEE80211_MAX_SUPP_RATES - srlen;
if (clen > elems->ext_supp_rates_len)
clen = elems->ext_supp_rates_len;
- memcpy(&bss->supp_rates[bss->supp_rates_len],
- elems->ext_supp_rates, clen);
- bss->supp_rates_len += clen;
+ memcpy(bss->supp_rates + srlen, elems->ext_supp_rates, clen);
+ srlen += clen;
}
+ if (srlen)
+ bss->supp_rates_len = srlen;
bss->wmm_used = elems->wmm_param || elems->wmm_info;
bss->uapsd_supported = is_uapsd_supported(elems);
--
1.6.2.5
^ permalink raw reply related
* RE: [RFC PATCH 1/1] mac80211: Disable cfg80211 assoc timeout warning
From: ext-saravanan.dhanabal @ 2010-04-28 13:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
In-Reply-To: <1272275586.3619.13.camel@jlt3.sipsolutions.net>
OK. Please let me know about that fix after testing, so that I could follow it up.
-saravanan d.
________________________________________
From: ext Johannes Berg [johannes@sipsolutions.net]
Sent: Monday, April 26, 2010 12:53 PM
To: Dhanabal Saravanan (EXT-Sasken/Tampere)
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] mac80211: Disable cfg80211 assoc timeout warning
On Mon, 2010-04-26 at 12:49 +0300, Saravanan Dhanabal wrote:
> While the association response is queued and yet to be
> processed, if the interface goes down, ieee80211_stop
> marks work queue items as IEEE80211_WORK_ABORT. This
> creates assoc timeout warnings which are actually caused
> by if down. Those warnings could be avoided, since they
> are not beacuse of association response.
>
> This patch disables assoc timeout warnings if interface is
> not running.
I don't think this is the right fix, we just debated exactly this
problem too.
The right fix would be to make mac80211 kill the association work when
deauthentication is requested. We're testing that fix right now.
johannes
> Signed-off-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
> ---
> net/wireless/mlme.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> index 0855f0d..a3ab86c 100644
> --- a/net/wireless/mlme.c
> +++ b/net/wireless/mlme.c
> @@ -337,7 +337,7 @@ void cfg80211_send_assoc_timeout(struct net_device *dev, const u8 *addr)
> }
> }
>
> - WARN_ON(!done);
> + WARN_ON(netif_running(dev) && !done);
>
> wdev_unlock(wdev);
> }
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Antonio Quartulli @ 2010-04-28 12:47 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Luis Correia, linux-wireless, users
In-Reply-To: <20100427111520.GA10969@ritirata.org>
On mar, apr 27, 2010 at 01:15:21 +0200, Antonio Quartulli wrote:
> On lun, apr 26, 2010 at 01:11:20 +0200, Helmut Schaa wrote:
> > Am Montag 26 April 2010 schrieb Helmut Schaa:
> > > Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> > > > rt2x00 had preliminary support for RT3070 based devices, but the support was
> > > > incomplete.
> > > > Update the RT3070 register initialization to be similar to the latest Ralink
> > > > vendor driver.
> > > >
> > > > With this patch my rt3070 based devices start showing a sign of life.
> > >
> > > Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
> > > more details.
> >
> > Antonio, did that patch also break rx on your PCI device with rt2872?
> > If not this is only needed for SoC.
> Hi, I cloned the wireless-testing git a few minutes ago.
> My card (rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003,
> rev: 0200) on miniPCI works correctly without any kind of problem.
> No hangs at all.
Hi all, I found out that after this commit:
commit 23812383c6b03afef44c4aa642500f8235c3d079
Author: Helmut Schaa <helmut.schaa@googlemail.com>
Date: Mon Apr 26 13:48:45 2010 +0200
rt2x00: rt2800lib: Fix rx path on SoC devices
my card becomes unstable, I mean that the connection lose packets and
sometimes it disassociates from the AP.
I also found that the singnal level reported by iwconfig is wrong (it
reports -191dBm)
Regards
>
> Regards
>
> >
> > Thanks,
> > Helmut
> >
> > > [...]
> > >
> > > > @@ -1643,18 +1653,12 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > > > {
> > > > u8 rfcsr;
> > > > u8 bbp;
> > > > + u32 reg;
> > > > + u16 eeprom;
> > > >
> > > > - if (rt2x00_is_usb(rt2x00dev) &&
> > > > - !rt2x00_rt_rev(rt2x00dev, RT3070, REV_RT3070E))
> > > > + if (!rt2x00_rt(rt2x00dev, RT3070))
> > > > return 0;
> > > >
> > > > - if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > > > - if (!rt2x00_rf(rt2x00dev, RF3020) &&
> > > > - !rt2x00_rf(rt2x00dev, RF3021) &&
> > > > - !rt2x00_rf(rt2x00dev, RF3022))
> > > > - return 0;
> > > > - }
> > >
> > > Any reason why you've removed this part? The following code was executed on
> > > pci and soc devices when they had an 3020, 3021 or 3022 rf.
> > >
> > > > /*
> > > > * Init RF calibration.
> > > > */
> > > > @@ -1665,13 +1669,13 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > > > rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
> > > > rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
> > > >
> > > > - if (rt2x00_is_usb(rt2x00dev)) {
> > > > + if (rt2x00_rt(rt2x00dev, RT3070)) {
> > > > rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > > > rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > > > rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > > > rt2800_rfcsr_write(rt2x00dev, 7, 0x70);
> > > > rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > > > - rt2800_rfcsr_write(rt2x00dev, 10, 0x71);
> > > > + rt2800_rfcsr_write(rt2x00dev, 10, 0x41);
> > > > rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > > > rt2800_rfcsr_write(rt2x00dev, 12, 0x7b);
> > > > rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > > > @@ -1684,48 +1688,25 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > > > rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > > > rt2800_rfcsr_write(rt2x00dev, 24, 0x16);
> > > > rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > > > - rt2800_rfcsr_write(rt2x00dev, 27, 0x03);
> > > > rt2800_rfcsr_write(rt2x00dev, 29, 0x1f);
> > > > - } else if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > > > - rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> > > > - rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> > > > - rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> > > > - rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> > > > - rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > > > - rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > > > - rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > > > - rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> > > > - rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> > > > - rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > > > - rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> > > > - rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > > > - rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> > > > - rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> > > > - rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > > > - rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> > > > - rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> > > > - rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> > > > - rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> > > > - rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> > > > - rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> > > > - rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > > > - rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> > > > - rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> > > > - rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> > > > - rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > > > - rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> > > > - rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> > > > - rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> > > > - rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
> > >
> > > This part is actually needed for getting rx to work on the SoC devices.
> > >
> > > Should I post a patch that adds this code again and is only executed on SoC
> > > devices with rf3020, 3021 and 3022?
> > >
> > > Thanks,
> > > Helmut
> > >
>
> --
> Antonio Quartulli
>
> Ognuno di noi, da solo, non vale nulla
> Ernesto "Che" Guevara
>
> _______________________________________________
> users mailing list
> users@rt2x00.serialmonkey.com
> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
--
Antonio Quartulli
Ognuno di noi, da solo, non vale nulla
Ernesto "Che" Guevara
^ permalink raw reply
* Re: [PATCH] Added configurable debug messages to libertastf
From: Steve deRosier @ 2010-04-28 13:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-wireless, javier, joe
In-Reply-To: <20100427131654.4ee04752.akpm@linux-foundation.org>
On Tue, Apr 27, 2010 at 1:16 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> I dunno what this pr_fmt() definition is doing here, but it has
> unpleasant effects with a x86_64 allmodconfig build:
>...
> so I cheerily deleted it.
Andrew,
I apologize for the pain. I was trying to comply with a comment to my
original patch:
On Wed, Apr 21, 2010 at 3:50 PM, Joe Perches <joe@perches.com> wrote:
>> +#define lbtf_pr_info(format, args...) \
>> + printk(KERN_INFO DRV_NAME": " format, ## args)
>> +#define lbtf_pr_err(format, args...) \
>> + printk(KERN_ERR DRV_NAME": " format, ## args)
>> +#define lbtf_pr_alert(format, args...) \
>> + printk(KERN_ALERT DRV_NAME": " format, ## args)
>
> I think it'd be better to add
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> and use the more standard pr_<level>s.
Unfortunately it turned into a mess, partly due to me wanting to keep
the definition in only one place (my .h file) for the module, and
partly to my lack of full understanding of the pr_fmt macro.
"cheerily" deleting it is fine. I'll followup with a second (better)
patch for that part if I don't like the result.
Thanks,
- Steve
^ permalink raw reply
* Re: [rt2x00-users] [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Helmut Schaa @ 2010-04-28 12:56 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: Luis Correia, linux-wireless, users
In-Reply-To: <20100428124736.GA8637@ritirata.org>
Am Mittwoch 28 April 2010 schrieb Antonio Quartulli:
> On mar, apr 27, 2010 at 01:15:21 +0200, Antonio Quartulli wrote:
> > On lun, apr 26, 2010 at 01:11:20 +0200, Helmut Schaa wrote:
> > > Am Montag 26 April 2010 schrieb Helmut Schaa:
> > > > Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> > > > > rt2x00 had preliminary support for RT3070 based devices, but the support was
> > > > > incomplete.
> > > > > Update the RT3070 register initialization to be similar to the latest Ralink
> > > > > vendor driver.
> > > > >
> > > > > With this patch my rt3070 based devices start showing a sign of life.
> > > >
> > > > Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
> > > > more details.
> > >
> > > Antonio, did that patch also break rx on your PCI device with rt2872?
> > > If not this is only needed for SoC.
> > Hi, I cloned the wireless-testing git a few minutes ago.
> > My card (rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003,
> > rev: 0200) on miniPCI works correctly without any kind of problem.
> > No hangs at all.
>
> Hi all, I found out that after this commit:
>
> commit 23812383c6b03afef44c4aa642500f8235c3d079
> Author: Helmut Schaa <helmut.schaa@googlemail.com>
> Date: Mon Apr 26 13:48:45 2010 +0200
>
> rt2x00: rt2800lib: Fix rx path on SoC devices
>
> my card becomes unstable, I mean that the connection lose packets and
> sometimes it disassociates from the AP.
> I also found that the singnal level reported by iwconfig is wrong (it
> reports -191dBm)
Uhhh, are you 100% sure? The patch doesn't touch any PCI code at all.
Maybe the card was unstable before already? Could you please verify again?
Thanks you very much for your testing, it's really appreciated.
Helmut
^ permalink raw reply
* Re: [ath9k-devel] ath9k: noise floor calibration process
From: Holger Schurig @ 2010-04-28 12:53 UTC (permalink / raw)
To: RHS Linux User
Cc: Benoit PAPILLAULT, ath9k-devel, linux-wireless@vger.kernel.org
In-Reply-To: <Pine.LNX.3.95.1100428051914.9331G-100000@nei>
> In the USA Amateur radio operators can use 1000 Watts (under certain
> conditions) !!
Don't count on the 1000 W. Most countries have tight restrictions, only
allowing certain frequencies, bandwiths, max PEP, max ERP, max EIRP, max
electric field, max magnetic fields.
In Germany, with my license class, I can use up to 75W PEP in the frequency
range 2320-2450 MHz. So, way less than 1000W. But I don't care, I wouldn't
want to use 1000 W anyway. That's quite dangerous, e.g. if someone moves too
near to the transmitting antenna.
> It is VERY surprising that no chips I am aware of provide directly for
> support of an external low noise preamp AND on a seperate coax a REAL
> amplifier.
However, as licensed ham radio op, I'm allowed to build and use self-build
equipment. That means, I'm not restricted to use only certified devices, e.g.
I don't need some FCC or ZZF or whatever number on my equipment. So I'm
perfectly eligible to add some pre-amp. And guess what, for frequencies above
100 MHz it's quite common to use low-noise pre-amps. Many HAMs do this, and
also every satellite dish LNB does this.
I don't no chip "allowing" me this, I simply attach the pre-amp as near to the
antenna as possible. How would a chip be able to prevent that anyway ?!?
Any WLAN chip provides for a separate coax. Again, how would a chip prevent
against that? Only some hybrid chip with built-in antenne could possible
prevent me doing that. But maybe you don't mean chips, but devices? Most USB
dongles that I've seen won't provide a coax connector. But I have a bunch of
PC-Card wlan cards with some SMA (or similar) coax connectors. And for Mini-
PCI cards it's the common case to provide some coax socket.
> Now two high powered, low noise Acess Points with a clear line of sight
> would give some real range!
Clear line of sight is nice, clear fresnel zone would be better.
Actually, what you're talking already happens already. It's called HAMNET.
Some english language link that I found:
http://db0fhn.efi.fh-nuernberg.de/doku.php?id=projects:wlan:hamnet
Oh, and they use atheros hardware :-)
^ permalink raw reply
* Re: [ath9k-devel] ath9k: noise floor calibration process
From: RHS Linux User @ 2010-04-28 9:24 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: ath9k-devel, linux-wireless@vger.kernel.org
In-Reply-To: <4BD7D005.5080301@free.fr>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 8107 bytes --]
Hi Benoit,
Yes. Having a patent is nice and probably significant too.
However, if using a preamp with a low noise figure results in
more signals or stronger (more error free) signals, then it IS
better than the chip itself !!
It is VERY surprising that no chips I am aware of provide directly for
support of an external low noise preamp AND on a seperate coax a REAL
amplifier.
In the USA Amateur radio operators can use 1000 Watts (under certain
conditions) !!
Now two high powered, low noise Acess Points with a clear line of sight
would give some real range!
warm regards,
Wiz
On Wed, 28 Apr 2010, Benoit PAPILLAULT wrote:
> RHS Linux User a écrit :
> > Hi All,
> >
> > <preaching>
> >
> > The chip *FOR SURE* *CANNOT* measure the thermal noise level!! It isn't
> > that sensitive. That said under some conditions it CAN measure the
> > local interference level which IS useful.
> >
> In fact, that's what I thought first, but according to Atheros patent,
> it can. It seems pretty logic in fact : if you have no real signal at
> the input, you are measuring ambient noise. A spectrum analyzer is able
> to do it as well.
>
> Sensitivity is the ability to decode 802.11 modulation out of the signal
> received (which includes any kind of noise). Using the formulas below,
> I measure the minimum signal levels of 802.11 packets by moving away
> from an AP and I indeed found -95dBm which is the typical sensitivity
> levels of an Atheros chip.
> > I am *VERY MUCH* in favor of making real time level measurements of
> > various parts of real packets easy to use! Troubleshooting becomes so
> > much easier :).
> >
> > </preaching>
> >
> > Great ideas !!
> >
> > FWIW - I have on occasion used a low noise preamp to feed the chip.
> > Many more signals are detectable which "proves" the chip by itself *IS
> > NOT* that sensitive. Try it yourself !
> >
> Sure, in fact, I /think/ the thermal noise I'm talking is generated
> inside the first RX amplifier (it's probably generated in every RX
> amplifier, but the first is the biggest since it's amplified more than
> the others). So, if you put a low noise preamp, you are feeding the chip
> with more signal at the input but the chip has still the same amount of
> noise. Am I correct?
> > Have fun,
> >
> > Wiz
> >
> Regards,
> Benoit
> >
> > On Tue, 27 Apr 2010, Benoit PAPILLAULT wrote:
> >
> >
> >> Hello,
> >>
> >> In order to move forward with noise & signal reporting, I'd like to
> >> share my current understanding of the way ath9k HW is working before
> >> sending patches (unfortunately, I did the work before the introduction
> >> of ar9003... so I need to redo the work).
> >>
> >> The ultimate purpose of this work is to be able to measure signal levels
> >> (and noise if possible) as accurately as a spectrum analyzer or power meter.
> >>
> >> First, signal level reporting. It is reported in a per packet basis in
> >> RX descriptors. There are 7 fields:
> >> AR_RxRSSIAnt00 0x000000ff rs_rssi_ctl0
> >> AR_RxRSSIAnt01 0x0000ff00 rs_rssi_ctl1
> >> AR_RxRSSIAnt02 0x00ff0000 rs_rssi_ctl2
> >> AR_RxRSSIAnt10 0x000000ff rs_rssi_ext0
> >> AR_RxRSSIAnt11 0x0000ff00 rs_rssi_ext1
> >> AR_RxRSSIAnt12 0x00ff0000 rs_rssi_ext2
> >> AR_RxRSSICombined 0xff000000 rs_rssi
> >>
> >> Each value is for a 20 MHz wide channel, on the 3 RX chains. "ctl" is
> >> for the primary channel and "ext" is for the secondary channel (using
> >> the 802.11n words). The latter rs_rssi is the sum of the 6 previous
> >> value. However, since each value is dB, the sum is not an arithmetic
> >> sum. Each field is a signed value and the value -128 means that no
> >> measurement has been done (no RX chain, RX chain disabled, no secondary
> >> channel, ...). It seems that in some cases, the combined value is just
> >> plain wrong. Here are few examples:
> >>
> >> RSSI: ctl=(10,7,-128) ext=(-128,-128,-128) => 12 (11.76) correct
> >>
> >> RSSI: ctl=(38,29,-128) ext=(69,-84,-101) => -22 incorrect!!!
> >>
> >>
> >> Next, noise floor calibration. From what I understand, signal levels is
> >> measured using the AGC + RX amplifiers gain (RF, IF and BB). However,
> >> the various gains are not really accurate, only the relative gain are
> >> accurate. This means that reading a signal value of -100dBm might not
> >> exactly means -100dBm. There is a delta between real signal and measured
> >> value. In order to know this value, we need a calibration process with a
> >> known signal.
> >>
> >> One know signal is thermal noise. Thermal noise is generated in any
> >> resistor and can be computed using the well know value N = kTB. For a 20
> >> MHz bandwidth, this gives -101dBm. If the HW tries to measure signal
> >> strength when the network is supposed to be idle (during SIFS) and with
> >> RX/TX switch disabled (?), then it will in fact measure the thermal
> >> noise at the RX input.
> >>
> >> So, we have :
> >>
> >> Real noise (-101dBm) = Measured noise + delta
> >>
> >> There are type of registers to control noise floor calibration :
> >>
> >> - control register at 0x9860 (AR_PHY_AGC_CONTROL)
> >>
> >> This register allows 3 differents operations :
> >>
> >> 1. start noise floor measurement
> >>
> >> write AR_PHY_MAXCCA_PWR (AR_PHY_CCA & 0x000001ff) : this is apparently
> >> a max value
> >> for noise floor
> >> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
> >> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
> >> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
> >>
> >> When channel has been changed however, the noise floor needs to be
> >> updated immediately, so AR_PHY_AGC_CONTROL_NO_UPDATE_NF should be
> >> cleared in this particular case. Otherwise, the chip is no longer
> >> receiving (problem since CCA is defined with noise floor as reference).
> >>
> >> 2. read noise floor measurement result
> >>
> >> check REG_READ(ah, AR_PHY_AGC_CONTROL) & AR_PHY_AGC_CONTROL_NF
> >> if 0 (noise floor calibration is finished), read AR_PHY_MINCCA_PWR :
> >> nf = MS(REG_READ(ah, AR_PHY_CCA), AR_PHY_MINCCA_PWR = 0x0ff80000)
> >>
> >> 3. write noise floor reference
> >>
> >> write AR_PHY_MAXCCA_PWR (the value has not the same meaning as
> >> operation 1!)
> >> REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
> >> REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
> >> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
> >>
> >> - data register at 0x9864 (AR_PHY_CCA, + more location for other RX chains)
> >>
> >> The fields are different for AR9280+ chipsets, but the mechanism is
> >> the same.
> >>
> >> AR_PHY_MAXCCA_PWR 0x000001ff (half dBm unit!)
> >> AR_PHY_CCA_THRESH62 0x0007f000
> >> AR_PHY_MINCCA_PWR 0x0ff80000
> >>
> >> Now, we have :
> >>
> >> Real signal = Measured signal + delta
> >> = RSSI + Noise floor + delta
> >> = RSSI + (-101 dBm)
> >>
> >> Real noise is not thermal noise. There are a lot of definition for noise
> >> since noise is NOT signal. Of course, noise includes thermal noise.
> >> Since the noise measured by the chip is variable, I think we could do :
> >>
> >> - Noise floor = minimum (Noise floor measures)
> >> - Noise = moving average (Noise floor measures) + delta
> >> with delta = (-101 dBm) - Noise floor
> >>
> >> I'd like to get comments before sending patches. Since ath5k and ath9k
> >> are quite close, I'm pretty sure a similar (if not same) process is used
> >> on ath5k.
> >>
> >> Regards,
> >> Benoit
> >>
> >> _______________________________________________
> >> ath9k-devel mailing list
> >> ath9k-devel@lists.ath9k.org
> >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >>
> >>
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel@lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
> >
>
^ permalink raw reply
* [patch] iwl: cleanup: remove unneeded error handling
From: Dan Carpenter @ 2010-04-28 9:01 UTC (permalink / raw)
To: Samuel Ortiz
Cc: Zhu Yi, Intel Linux Wireless, John W. Linville, Andrew Morton,
Alexey Dobriyan, linux-wireless, netdev, linux-kernel,
kernel-janitors
This is just a cleanup and doesn't change how the code works.
debugfs_create_dir() and debugfs_create_file() return an error pointer
(-ENODEV) if CONFIG_DEBUG_FS is not enabled, otherwise if an error occurs
they return NULL. This is how they are implemented and what it says in
the DebugFS documentation. DebugFS can not be compiled as a module.
As a result, we only need to check for error pointers and particularly
-ENODEV one time to know that DebugFS is enabled. This patch keeps the
first check for error pointers and removes the rest.
The other reason for this patch, is that it silences some Smatch warnings.
Smatch sees the condition "(result != -ENODEV)" and assumes that it's
possible for "result" to equal -ENODEV. If it were possible it would lead
to an error pointer dereference. But since it's not, we can just remove
the check.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/iwmc3200wifi/debugfs.c b/drivers/net/wireless/iwmc3200wifi/debugfs.c
index cbb81be..10eeeeb 100644
--- a/drivers/net/wireless/iwmc3200wifi/debugfs.c
+++ b/drivers/net/wireless/iwmc3200wifi/debugfs.c
@@ -438,40 +438,10 @@ int iwm_debugfs_init(struct iwm_priv *iwm)
snprintf(devdir, sizeof(devdir), "%s", wiphy_name(iwm_to_wiphy(iwm)));
iwm->dbg.devdir = debugfs_create_dir(devdir, iwm->dbg.rootdir);
- result = PTR_ERR(iwm->dbg.devdir);
- if (IS_ERR(iwm->dbg.devdir) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create devdir: %d\n", result);
- goto error;
- }
-
iwm->dbg.dbgdir = debugfs_create_dir("debug", iwm->dbg.devdir);
- result = PTR_ERR(iwm->dbg.dbgdir);
- if (IS_ERR(iwm->dbg.dbgdir) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create dbgdir: %d\n", result);
- goto error;
- }
-
iwm->dbg.rxdir = debugfs_create_dir("rx", iwm->dbg.devdir);
- result = PTR_ERR(iwm->dbg.rxdir);
- if (IS_ERR(iwm->dbg.rxdir) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create rx dir: %d\n", result);
- goto error;
- }
-
iwm->dbg.txdir = debugfs_create_dir("tx", iwm->dbg.devdir);
- result = PTR_ERR(iwm->dbg.txdir);
- if (IS_ERR(iwm->dbg.txdir) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create tx dir: %d\n", result);
- goto error;
- }
-
iwm->dbg.busdir = debugfs_create_dir("bus", iwm->dbg.devdir);
- result = PTR_ERR(iwm->dbg.busdir);
- if (IS_ERR(iwm->dbg.busdir) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create bus dir: %d\n", result);
- goto error;
- }
-
if (iwm->bus_ops->debugfs_init) {
result = iwm->bus_ops->debugfs_init(iwm, iwm->dbg.busdir);
if (result < 0) {
@@ -480,27 +450,15 @@ int iwm_debugfs_init(struct iwm_priv *iwm)
}
}
-
iwm->dbg.dbg_level = IWM_DL_NONE;
iwm->dbg.dbg_level_dentry =
debugfs_create_file("level", 0200, iwm->dbg.dbgdir, iwm,
&fops_iwm_dbg_level);
- result = PTR_ERR(iwm->dbg.dbg_level_dentry);
- if (IS_ERR(iwm->dbg.dbg_level_dentry) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create dbg_level: %d\n", result);
- goto error;
- }
-
iwm->dbg.dbg_modules = IWM_DM_DEFAULT;
iwm->dbg.dbg_modules_dentry =
debugfs_create_file("modules", 0200, iwm->dbg.dbgdir, iwm,
&fops_iwm_dbg_modules);
- result = PTR_ERR(iwm->dbg.dbg_modules_dentry);
- if (IS_ERR(iwm->dbg.dbg_modules_dentry) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create dbg_modules: %d\n", result);
- goto error;
- }
for (i = 0; i < __IWM_DM_NR; i++)
add_dbg_module(iwm->dbg, iwm_debug_module[i].name,
@@ -509,39 +467,18 @@ int iwm_debugfs_init(struct iwm_priv *iwm)
iwm->dbg.txq_dentry = debugfs_create_file("queues", 0200,
iwm->dbg.txdir, iwm,
&iwm_debugfs_txq_fops);
- result = PTR_ERR(iwm->dbg.txq_dentry);
- if (IS_ERR(iwm->dbg.txq_dentry) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create tx queue: %d\n", result);
- goto error;
- }
iwm->dbg.tx_credit_dentry = debugfs_create_file("credits", 0200,
iwm->dbg.txdir, iwm,
&iwm_debugfs_tx_credit_fops);
- result = PTR_ERR(iwm->dbg.tx_credit_dentry);
- if (IS_ERR(iwm->dbg.tx_credit_dentry) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create tx credit: %d\n", result);
- goto error;
- }
iwm->dbg.rx_ticket_dentry = debugfs_create_file("tickets", 0200,
iwm->dbg.rxdir, iwm,
&iwm_debugfs_rx_ticket_fops);
- result = PTR_ERR(iwm->dbg.rx_ticket_dentry);
- if (IS_ERR(iwm->dbg.rx_ticket_dentry) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create rx ticket: %d\n", result);
- goto error;
- }
iwm->dbg.fw_err_dentry = debugfs_create_file("last_fw_err", 0200,
iwm->dbg.dbgdir, iwm,
&iwm_debugfs_fw_err_fops);
- result = PTR_ERR(iwm->dbg.fw_err_dentry);
- if (IS_ERR(iwm->dbg.fw_err_dentry) && (result != -ENODEV)) {
- IWM_ERR(iwm, "Couldn't create last FW err: %d\n", result);
- goto error;
- }
-
return 0;
^ permalink raw reply related
* Re: [PATCH] rt2x00: rt2800lib: update rfcsr & bbp init code for SoC devices
From: Gertjan van Wingerde @ 2010-04-28 8:12 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, Ivo van Doorn, linux-wireless
In-Reply-To: <201004280958.59704.helmut.schaa@googlemail.com>
2010/4/28 Helmut Schaa <helmut.schaa@googlemail.com>:
> Update the rfcsr and bbp init code for SoC devices to match with the
> latest Ralink driver.
>
> To have better control over which values are used for the register
> initialization create a new function rt2800_is_305x_soc which checks
> for SoC interface type, the correct RT chipset and the correct RF
> chipset. This is based on the assumption that all rt305x SoC devices
> use a rt2872 and rf3020/rf3021/rf3022.
>
> In case an unknown RF chipset is found on a SoC device with a rt2872
> don't treat it as rt305x and just print a message.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Looks good to me.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
>
> Gertjan, this approach should be pretty safe and if there really exists
> a rt305x board with a different rf chipset we'll get a log message.
>
> At the moment rt2800_is_305x_soc is only used in rt2800lib.c but maybe
> it's worth to move it to one of the headers?
Well, at the moment I don't see a use case beyond rt2800lib.c.
So, let's leave it where it is now, and we'll move it when the need to
move it to
a header file when the need arises.
>
> drivers/net/wireless/rt2x00/rt2800lib.c | 43 ++++++++++++++++++++++++------
> 1 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 50f4451..e7a61a3 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -76,6 +76,23 @@ MODULE_LICENSE("GPL");
> rt2800_regbusy_read((__dev), H2M_MAILBOX_CSR, \
> H2M_MAILBOX_CSR_OWNER, (__reg))
>
> +static inline bool rt2800_is_305x_soc(struct rt2x00_dev *rt2x00dev)
> +{
> + /* check for rt2872 on SoC */
> + if (!rt2x00_is_soc(rt2x00dev) ||
> + !rt2x00_rt(rt2x00dev, RT2872))
> + return false;
> +
> + /* we know for sure that these rf chipsets are used on rt305x boards */
> + if (rt2x00_rf(rt2x00dev, RF3020) ||
> + rt2x00_rf(rt2x00dev, RF3021) ||
> + rt2x00_rf(rt2x00dev, RF3022))
> + return true;
> +
> + NOTICE(rt2x00dev, "Unknown RF chipset on rt305x\n");
> + return false;
> +}
> +
> static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
> const unsigned int word, const u8 value)
> {
> @@ -1556,6 +1573,9 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
> rt2800_wait_bbp_ready(rt2x00dev)))
> return -EACCES;
>
> + if (rt2800_is_305x_soc(rt2x00dev))
> + rt2800_bbp_write(rt2x00dev, 31, 0x08);
> +
> rt2800_bbp_write(rt2x00dev, 65, 0x2c);
> rt2800_bbp_write(rt2x00dev, 66, 0x38);
>
> @@ -1576,6 +1596,9 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
> rt2800_bbp_write(rt2x00dev, 79, 0x13);
> rt2800_bbp_write(rt2x00dev, 80, 0x05);
> rt2800_bbp_write(rt2x00dev, 81, 0x33);
> + } else if (rt2800_is_305x_soc(rt2x00dev)) {
> + rt2800_bbp_write(rt2x00dev, 78, 0x0e);
> + rt2800_bbp_write(rt2x00dev, 80, 0x08);
> } else {
> rt2800_bbp_write(rt2x00dev, 81, 0x37);
> }
> @@ -1596,12 +1619,16 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
> if (rt2x00_rt_rev_gte(rt2x00dev, RT3070, REV_RT3070F) ||
> rt2x00_rt_rev_gte(rt2x00dev, RT3071, REV_RT3071E) ||
> rt2x00_rt_rev_gte(rt2x00dev, RT3090, REV_RT3090E) ||
> - rt2x00_rt_rev_gte(rt2x00dev, RT3390, REV_RT3390E))
> + rt2x00_rt_rev_gte(rt2x00dev, RT3390, REV_RT3390E) ||
> + rt2800_is_305x_soc(rt2x00dev))
> rt2800_bbp_write(rt2x00dev, 103, 0xc0);
> else
> rt2800_bbp_write(rt2x00dev, 103, 0x00);
>
> - rt2800_bbp_write(rt2x00dev, 105, 0x05);
> + if (rt2800_is_305x_soc(rt2x00dev))
> + rt2800_bbp_write(rt2x00dev, 105, 0x01);
> + else
> + rt2800_bbp_write(rt2x00dev, 105, 0x05);
> rt2800_bbp_write(rt2x00dev, 106, 0x35);
>
> if (rt2x00_rt(rt2x00dev, RT3071) ||
> @@ -1618,11 +1645,6 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
> rt2800_bbp_write(rt2x00dev, 138, value);
> }
>
> - if (rt2x00_rt(rt2x00dev, RT2872)) {
> - rt2800_bbp_write(rt2x00dev, 31, 0x08);
> - rt2800_bbp_write(rt2x00dev, 78, 0x0e);
> - rt2800_bbp_write(rt2x00dev, 80, 0x08);
> - }
>
> for (i = 0; i < EEPROM_BBP_SIZE; i++) {
> rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i, &eeprom);
> @@ -1709,7 +1731,7 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> !rt2x00_rt(rt2x00dev, RT3071) &&
> !rt2x00_rt(rt2x00dev, RT3090) &&
> !rt2x00_rt(rt2x00dev, RT3390) &&
> - !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
> + !rt2800_is_305x_soc(rt2x00dev))
> return 0;
>
> /*
> @@ -1777,7 +1799,7 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
> rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
> rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
> - } else if (rt2x00_rt(rt2x00dev, RT2872)) {
> + } else if (rt2800_is_305x_soc(rt2x00dev)) {
> rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> @@ -1808,6 +1830,9 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
> + rt2800_rfcsr_write(rt2x00dev, 30, 0x00);
> + rt2800_rfcsr_write(rt2x00dev, 31, 0x00);
> + return 0;
> }
>
> if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
> --
> 1.6.4.2
>
>
^ permalink raw reply
* kernel warning on 2.6.33 ath9k
From: Xu, Martin @ 2010-04-28 8:01 UTC (permalink / raw)
To: ath9k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org
In-Reply-To: <1272438045.2772.6.camel@jm-desktop>
SGkNCkkgZm91bmQgdGhhdCBrZXJuZWwgcmVwb3J0cyBiZWxvdyB3YXJuaW5nIHdoZW4gdXNpbmcg
YXRoOWsgaW4ga2VybmVsIDIuNi4zMy4NClNvbWVvbmUgY2FuIGtpbmRseSB0ZWxsIG1lIHdoZXRo
ZXIgaXQgaXMgdGhlIG5ldyBmb3VuZCBpc3N1ZSBvciB0aGUgaXNzdWUgaXMga25vd24gYW5kIGhh
cyBiZWVuIGZpeGVkIGluIGxhdGVyIGNvbW1pdCBpbiBnaXQgdHJlZT8NClRoYW5rcyENCg0KLS0t
LS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0tLS0tDQpXQVJOSU5HOiBhdCBrZXJuZWwvc29m
dGlycS5jOjE0MyBsb2NhbF9iaF9lbmFibGVfaXArMHgzMi8weDc2KCkNCkhhcmR3YXJlIG5hbWU6
IEFPNTMyaCAgICAgICAgICANCk1vZHVsZXMgbGlua2VkIGluOiBjYmMgZWNyeXB0ZnMgYXRoOWsg
YXRoOWtfY29tbW9uIGJhdHRlcnkgYXRsMWMgam95ZGV2IGF0aDlrX2h3IHV2Y3ZpZGVvDQpQaWQ6
IDg1MCwgY29tbTogd3BhX3N1cHBsaWNhbnQgTm90IHRhaW50ZWQgMi42LjMzLjItOC4xLW5ldGJv
b2sgIzENCkNhbGwgVHJhY2U6DQogWzxjMTAzMDk3OD5dIHdhcm5fc2xvd3BhdGhfY29tbW9uKzB4
NjYvMHg3ZA0KIFs8YzEwMzVhNzQ+XSA/IGxvY2FsX2JoX2VuYWJsZV9pcCsweDMyLzB4NzYNCiBb
PGMxMDMwOTljPl0gd2Fybl9zbG93cGF0aF9udWxsKzB4ZC8weDEwDQogWzxjMTAzNWE3ND5dIGxv
Y2FsX2JoX2VuYWJsZV9pcCsweDMyLzB4NzYNCiBbPGMxNDc4OWMwPl0gX3Jhd19zcGluX3VubG9j
a19iaCsweDE3LzB4MTkNCiBbPGY4NzFkYmQzPl0gYXRoX3R4X25vZGVfY2xlYW51cCsweGUwLzB4
ZjkgW2F0aDlrXQ0KIFs8YzEwM2FlNDY+XSA/IGxvY2tfdGltZXJfYmFzZSsweDIyLzB4NDENCiBb
PGY4NzFhMDA1Pl0gYXRoOWtfc3RhX25vdGlmeSsweDc0LzB4NzggW2F0aDlrXQ0KIFs8YzE0NDM5
ODc+XSBfX3N0YV9pbmZvX3VubGluaysweDEzOS8weDE4OQ0KIFs8Zjg3MTlmOTE+XSA/IGF0aDlr
X3N0YV9ub3RpZnkrMHgwLzB4NzggW2F0aDlrXQ0KIFs8YzE0NDM5ZmE+XSBzdGFfaW5mb191bmxp
bmsrMHgyMy8weDMxDQogWzxjMTQ0ODgzND5dIGllZWU4MDIxMV9zZXRfZGlzYXNzb2MrMHgxYmQv
MHgxZTMNCiBbPGMxNDQ4Y2Y4Pl0gaWVlZTgwMjExX21nZF9kZWF1dGgrMHgzYy8weGZlDQogWzxj
MTQ0ZGYyMT5dIGllZWU4MDIxMV9kZWF1dGgrMHgxNC8weDE2DQogWzxjMTQzYzNmYz5dIF9fY2Zn
ODAyMTFfbWxtZV9kZWF1dGgrMHhlOS8weGYyDQogWzxjMTQzZWVhMT5dIF9fY2ZnODAyMTFfZGlz
Y29ubmVjdCsweGNiLzB4MTJlDQogWzxjMTQ0MGI3ND5dIGNmZzgwMjExX3dleHRfc2l3bWxtZSsw
eDY0LzB4ODANCiBbPGMxNDQxY2Y2Pl0gaW9jdGxfc3RhbmRhcmRfY2FsbCsweDFkNy8weDI2Zg0K
IFs8YzEzOTI4MWI+XSA/IGRldl9nZXRfYnlfbmFtZV9yY3UrMHg3My8weDgwDQogWzxjMTM5Mjhk
OT5dID8gX19kZXZfZ2V0X2J5X25hbWUrMHg3MS8weDdlDQogWzxjMTQ0MWU4MT5dIHdleHRfaGFu
ZGxlX2lvY3RsKzB4ZjMvMHgxN2UNCiBbPGMxNDQwYjEwPl0gPyBjZmc4MDIxMV93ZXh0X3Npd21s
bWUrMHgwLzB4ODANCiBbPGMxMzk2NDEwPl0gZGV2X2lvY3RsKzB4NTc4LzB4NTk4DQogWzxjMTAw
OTFiOT5dID8gcmVzdG9yZV9pMzg3X2Z4c2F2ZSsweDU0LzB4NjYNCiBbPGMxMzg3YjQ0Pl0gc29j
a19pb2N0bCsweDFjZi8weDFkYg0KIFs8YzEwYjA5Nzk+XSB2ZnNfaW9jdGwrMHgyOC8weDkyDQog
WzxjMTM4Nzk3NT5dID8gc29ja19pb2N0bCsweDAvMHgxZGINCiBbPGMxMGIwZWQ2Pl0gZG9fdmZz
X2lvY3RsKzB4NDUzLzB4NDkxDQogWzxjMTM4ODIzMz5dID8gc3lzX3JlY3Ztc2crMHgyYy8weDQ3
DQogWzxjMTM4OTU0Mj5dID8gc3lzX3NvY2tldGNhbGwrMHgxNDcvMHgxOGMNCiBbPGMxMGIwZjQz
Pl0gc3lzX2lvY3RsKzB4MmYvMHg0OQ0KIFs8YzEwMDI3ZDA+XSBzeXNlbnRlcl9kb19jYWxsKzB4
MTIvMHgyNg0KDQo=
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: update rfcsr & bbp init code for SoC devices
From: Helmut Schaa @ 2010-04-28 7:58 UTC (permalink / raw)
To: John Linville; +Cc: Gertjan van Wingerde, Ivo van Doorn, linux-wireless
Update the rfcsr and bbp init code for SoC devices to match with the
latest Ralink driver.
To have better control over which values are used for the register
initialization create a new function rt2800_is_305x_soc which checks
for SoC interface type, the correct RT chipset and the correct RF
chipset. This is based on the assumption that all rt305x SoC devices
use a rt2872 and rf3020/rf3021/rf3022.
In case an unknown RF chipset is found on a SoC device with a rt2872
don't treat it as rt305x and just print a message.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
Gertjan, this approach should be pretty safe and if there really exists
a rt305x board with a different rf chipset we'll get a log message.
At the moment rt2800_is_305x_soc is only used in rt2800lib.c but maybe
it's worth to move it to one of the headers?
drivers/net/wireless/rt2x00/rt2800lib.c | 43 ++++++++++++++++++++++++------
1 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 50f4451..e7a61a3 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -76,6 +76,23 @@ MODULE_LICENSE("GPL");
rt2800_regbusy_read((__dev), H2M_MAILBOX_CSR, \
H2M_MAILBOX_CSR_OWNER, (__reg))
+static inline bool rt2800_is_305x_soc(struct rt2x00_dev *rt2x00dev)
+{
+ /* check for rt2872 on SoC */
+ if (!rt2x00_is_soc(rt2x00dev) ||
+ !rt2x00_rt(rt2x00dev, RT2872))
+ return false;
+
+ /* we know for sure that these rf chipsets are used on rt305x boards */
+ if (rt2x00_rf(rt2x00dev, RF3020) ||
+ rt2x00_rf(rt2x00dev, RF3021) ||
+ rt2x00_rf(rt2x00dev, RF3022))
+ return true;
+
+ NOTICE(rt2x00dev, "Unknown RF chipset on rt305x\n");
+ return false;
+}
+
static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
const unsigned int word, const u8 value)
{
@@ -1556,6 +1573,9 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
rt2800_wait_bbp_ready(rt2x00dev)))
return -EACCES;
+ if (rt2800_is_305x_soc(rt2x00dev))
+ rt2800_bbp_write(rt2x00dev, 31, 0x08);
+
rt2800_bbp_write(rt2x00dev, 65, 0x2c);
rt2800_bbp_write(rt2x00dev, 66, 0x38);
@@ -1576,6 +1596,9 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 79, 0x13);
rt2800_bbp_write(rt2x00dev, 80, 0x05);
rt2800_bbp_write(rt2x00dev, 81, 0x33);
+ } else if (rt2800_is_305x_soc(rt2x00dev)) {
+ rt2800_bbp_write(rt2x00dev, 78, 0x0e);
+ rt2800_bbp_write(rt2x00dev, 80, 0x08);
} else {
rt2800_bbp_write(rt2x00dev, 81, 0x37);
}
@@ -1596,12 +1619,16 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
if (rt2x00_rt_rev_gte(rt2x00dev, RT3070, REV_RT3070F) ||
rt2x00_rt_rev_gte(rt2x00dev, RT3071, REV_RT3071E) ||
rt2x00_rt_rev_gte(rt2x00dev, RT3090, REV_RT3090E) ||
- rt2x00_rt_rev_gte(rt2x00dev, RT3390, REV_RT3390E))
+ rt2x00_rt_rev_gte(rt2x00dev, RT3390, REV_RT3390E) ||
+ rt2800_is_305x_soc(rt2x00dev))
rt2800_bbp_write(rt2x00dev, 103, 0xc0);
else
rt2800_bbp_write(rt2x00dev, 103, 0x00);
- rt2800_bbp_write(rt2x00dev, 105, 0x05);
+ if (rt2800_is_305x_soc(rt2x00dev))
+ rt2800_bbp_write(rt2x00dev, 105, 0x01);
+ else
+ rt2800_bbp_write(rt2x00dev, 105, 0x05);
rt2800_bbp_write(rt2x00dev, 106, 0x35);
if (rt2x00_rt(rt2x00dev, RT3071) ||
@@ -1618,11 +1645,6 @@ int rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 138, value);
}
- if (rt2x00_rt(rt2x00dev, RT2872)) {
- rt2800_bbp_write(rt2x00dev, 31, 0x08);
- rt2800_bbp_write(rt2x00dev, 78, 0x0e);
- rt2800_bbp_write(rt2x00dev, 80, 0x08);
- }
for (i = 0; i < EEPROM_BBP_SIZE; i++) {
rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i, &eeprom);
@@ -1709,7 +1731,7 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
!rt2x00_rt(rt2x00dev, RT3071) &&
!rt2x00_rt(rt2x00dev, RT3090) &&
!rt2x00_rt(rt2x00dev, RT3390) &&
- !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
+ !rt2800_is_305x_soc(rt2x00dev))
return 0;
/*
@@ -1777,7 +1799,7 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
- } else if (rt2x00_rt(rt2x00dev, RT2872)) {
+ } else if (rt2800_is_305x_soc(rt2x00dev)) {
rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
@@ -1808,6 +1830,9 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
+ rt2800_rfcsr_write(rt2x00dev, 30, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 31, 0x00);
+ return 0;
}
if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH] ath9k: Added get_survey callback in order to get channel noise
From: Jouni Malinen @ 2010-04-28 7:00 UTC (permalink / raw)
To: Benoit Papillault
Cc: Luis Rodriguez, ath9k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1272406104-6870-1-git-send-email-benoit.papillault@free.fr>
On Tue, 2010-04-27 at 15:08 -0700, Benoit Papillault wrote:
> +static int ath9k_get_survey(struct ieee80211_hw *hw, int idx,
> + struct survey_info *survey)
> + struct ieee80211_conf *conf = &hw->conf;
> +
> + if (idx != 0)
> + return -ENOENT;
> +
> + survey->channel = conf->channel;
Are there any plans on providing this information from all channels? I
have assumed that the survey command was supposed to be used for
surveying all channels (e.g., to get information for auto-channel
selection) and returning something for the current channel is quite
limited subset of that. In other words, I would like to be able to run a
scan of all channels and then use NL80211_CMD_GET_SURVEY to fetch
additional per-channel information like noise (and also channel usage
statistics in case of ath9k) from the scanned channels.
- Jouni
^ permalink raw reply
* [PATCH 2/4] wl1271: Configure QOS nullfunc template for U-APSD
From: Luciano Coelho @ 2010-04-28 6:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Saravanan Dhanabal
In-Reply-To: <1272437402-28801-1-git-send-email-luciano.coelho@nokia.com>
From: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
When U-APSD is enabled, device is not sending power save
state notifications to AP using QOS nullfunc frames.
This patch configures nullfunc templates needed for U-APSD.
Signed-off-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index e53dfc9..26e8fb1 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -1708,6 +1708,10 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
+ ret = wl1271_build_qos_null_data(wl);
+ if (ret < 0)
+ goto out_sleep;
+
/* filter out all packets not from this BSSID */
wl1271_configure_filters(wl, 0);
--
1.6.3.3
^ permalink raw reply related
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