* [PATCH] rt2x00: remove now unused noise field from struct rxdone_entry_desc
From: cabtobma @ 2010-04-28 21:00 UTC (permalink / raw)
To: linux-wireless; +Cc: gwingerde, ivdoorn, John W. Linville
From: John W. Linville <linville@tuxdriver.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rt2x00/rt2800pci.c | 4 ----
drivers/net/wireless/rt2x00/rt2800usb.c | 4 ----
drivers/net/wireless/rt2x00/rt2x00queue.h | 2 --
3 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 0e52f17..89281d7 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -895,10 +895,6 @@ static void rt2800pci_fill_rxdone(struct queue_entry *entry,
(rt2x00_get_field32(rxwi2, RXWI_W2_RSSI0) +
rt2x00_get_field32(rxwi2, RXWI_W2_RSSI1)) / 2;
- rxdesc->noise =
- (rt2x00_get_field32(rxwi3, RXWI_W3_SNR0) +
- rt2x00_get_field32(rxwi3, RXWI_W3_SNR1)) / 2;
-
rxdesc->size = rt2x00_get_field32(rxwi0, RXWI_W0_MPDU_TOTAL_BYTE_COUNT);
/*
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index a716156..6f2a945 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -645,10 +645,6 @@ static void rt2800usb_fill_rxdone(struct queue_entry *entry,
(rt2x00_get_field32(rxwi2, RXWI_W2_RSSI0) +
rt2x00_get_field32(rxwi2, RXWI_W2_RSSI1)) / 2;
- rxdesc->noise =
- (rt2x00_get_field32(rxwi3, RXWI_W3_SNR0) +
- rt2x00_get_field32(rxwi3, RXWI_W3_SNR1)) / 2;
-
rxdesc->size = rt2x00_get_field32(rxwi0, RXWI_W0_MPDU_TOTAL_BYTE_COUNT);
/*
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.h b/drivers/net/wireless/rt2x00/rt2x00queue.h
index c1e482b..f519aba 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.h
@@ -183,7 +183,6 @@ enum rxdone_entry_desc_flags {
* @timestamp: RX Timestamp
* @signal: Signal of the received frame.
* @rssi: RSSI of the received frame.
- * @noise: Measured noise during frame reception.
* @size: Data size of the received frame.
* @flags: MAC80211 receive flags (See &enum mac80211_rx_flags).
* @dev_flags: Ralink receive flags (See &enum rxdone_entry_desc_flags).
@@ -197,7 +196,6 @@ struct rxdone_entry_desc {
u64 timestamp;
int signal;
int rssi;
- int noise;
int size;
int flags;
int dev_flags;
--
1.6.6.1
^ permalink raw reply related
* [PATCH] mac80211: fix paged defragmentation
From: Abhijeet Kolekar @ 2010-04-28 20:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Abhijeet Kolekar
Fix the bug at
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2194
Paged RX skb patch broke the fragmentation while checking the sequnce
control bit in headers. Instead of doing linearization of all the frames
to check seq_ctrl bit just copy the bits.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
---
net/mac80211/rx.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 72efbd8..4126392 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1234,14 +1234,16 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
{
struct ieee80211_hdr *hdr;
u16 sc;
- __le16 fc;
+ __le16 fc, seq_ctrl;
unsigned int frag, seq;
struct ieee80211_fragment_entry *entry;
struct sk_buff *skb;
hdr = (struct ieee80211_hdr *)rx->skb->data;
fc = hdr->frame_control;
- sc = le16_to_cpu(hdr->seq_ctrl);
+ skb_copy_bits(rx->skb, offsetof(struct ieee80211_hdr, seq_ctrl),
+ &seq_ctrl, sizeof(seq_ctrl));
+ sc = le16_to_cpu(seq_ctrl);
frag = sc & IEEE80211_SCTL_FRAG;
if (likely((!ieee80211_has_morefrags(fc) && frag == 0) ||
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 2/2] mac80211: fix supported rates IE if AP doesn't give us it's rates
From: John W. Linville @ 2010-04-28 20:33 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20100428133336.GA2527@dhcp-lab-161.englab.brq.redhat.com>
On Wed, Apr 28, 2010 at 03:33:37PM +0200, Stanislaw Gruszka wrote:
> 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 :)
It is fairly late in the 2.6.34 cycle, and it isn't obvious to me
that these fix any sort of regression. Am I wrong?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] libertas_tf: avoid warning about pr_fmt redefinition
From: John W. Linville @ 2010-04-28 20:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Steve deRosier, John W. Linville
Also includes a minor cleanup regarding quotation of a standard kernel
header file...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/libertas_tf/cmd.c | 2 +-
drivers/net/wireless/libertas_tf/deb_defs.h | 2 --
drivers/net/wireless/libertas_tf/if_usb.c | 3 ++-
drivers/net/wireless/libertas_tf/libertas_tf.h | 2 ++
drivers/net/wireless/libertas_tf/main.c | 4 ++--
5 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/libertas_tf/cmd.c b/drivers/net/wireless/libertas_tf/cmd.c
index fba1e94..8945afd 100644
--- a/drivers/net/wireless/libertas_tf/cmd.c
+++ b/drivers/net/wireless/libertas_tf/cmd.c
@@ -7,7 +7,7 @@
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*/
-#include "deb_defs.h"
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/slab.h>
diff --git a/drivers/net/wireless/libertas_tf/deb_defs.h b/drivers/net/wireless/libertas_tf/deb_defs.h
index 9a3e92b..ae75396 100644
--- a/drivers/net/wireless/libertas_tf/deb_defs.h
+++ b/drivers/net/wireless/libertas_tf/deb_defs.h
@@ -9,8 +9,6 @@
#define DRV_NAME "libertas_tf"
#endif
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/spinlock.h>
#ifdef CONFIG_LIBERTAS_THINFIRM_DEBUG
diff --git a/drivers/net/wireless/libertas_tf/if_usb.c b/drivers/net/wireless/libertas_tf/if_usb.c
index 125f54d..4412c27 100644
--- a/drivers/net/wireless/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/libertas_tf/if_usb.c
@@ -9,7 +9,8 @@
*/
#define DRV_NAME "lbtf_usb"
-#include "deb_defs.h"
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include "libertas_tf.h"
#include "if_usb.h"
diff --git a/drivers/net/wireless/libertas_tf/libertas_tf.h b/drivers/net/wireless/libertas_tf/libertas_tf.h
index 4cc42dd..fbbaaae 100644
--- a/drivers/net/wireless/libertas_tf/libertas_tf.h
+++ b/drivers/net/wireless/libertas_tf/libertas_tf.h
@@ -13,6 +13,8 @@
#include <linux/kthread.h>
#include <net/mac80211.h>
+#include "deb_defs.h"
+
#ifndef DRV_NAME
#define DRV_NAME "libertas_tf"
#endif
diff --git a/drivers/net/wireless/libertas_tf/main.c b/drivers/net/wireless/libertas_tf/main.c
index 61d6a7b..bb46665 100644
--- a/drivers/net/wireless/libertas_tf/main.c
+++ b/drivers/net/wireless/libertas_tf/main.c
@@ -7,12 +7,12 @@
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*/
-#include "deb_defs.h"
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/slab.h>
+#include <linux/etherdevice.h>
#include "libertas_tf.h"
-#include "linux/etherdevice.h"
#define DRIVER_RELEASE_VERSION "004.p0"
/* thinfirm version: 5.132.X.pX */
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] ath9k: Added get_survey callback in order to get channel noise
From: Benoit PAPILLAULT @ 2010-04-28 20:13 UTC (permalink / raw)
To: Jouni Malinen
Cc: Luis Rodriguez, ath9k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1272438045.2772.6.camel@jm-desktop>
Jouni Malinen a écrit :
> 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
>
Hi Jouni,
I dig into the source code to understand the use of "idx" and having the
value for all scanned channels sounds a good plan. However :
- when doing a normal scan (iw dev wlan0 scan), the noise floor
calibration is started in a special mode, so I don't know if the results
is accurate enought.
- the first calibration takes some times .... more than the scan itself.
So, you cannot get a valid value before switching to the next channel.
Anyway, how idx is supposed to be used? From 0 ... up to the callback
returning -ENOENT ?
Do we need to keep a table with noise for each channel and return those
where we have a value, in which case idx cannot be used as an index into
this table ?
Regards,
Benoit
^ permalink raw reply
* Re: AW: [PATCH] ath9k: remove usage of deprecated noise value
From: Benoit PAPILLAULT @ 2010-04-28 20:06 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <497730.40090.qm@web51403.mail.re2.yahoo.com>
Joerg Pommnitz a écrit :
> ----- Ursprüngliche Mail ----
>
>
>> From: Benoit PAPILLAULT <benoit.papillault@free.fr>
>> I'll try then to implement it for ath5k (already done?), ar9170,
>> zd1211rw (if possible), rt2800usb/pci.
>>
> For ath5k see
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=55ee82b500551f80720de57a00d2990d56cf08a8
>
>
>
>
Thanks. I've used that for the ath9k variant.
Regards,
Benoit
^ permalink raw reply
* AW: [PATCH] ath9k: remove usage of deprecated noise value
From: Joerg Pommnitz @ 2010-04-28 19:38 UTC (permalink / raw)
To: Benoit PAPILLAULT; +Cc: linux-wireless
In-Reply-To: <4BD7399B.9040104@free.fr>
----- Ursprüngliche Mail ----
> From: Benoit PAPILLAULT <benoit.papillault@free.fr>
> I'll try then to implement it for ath5k (already done?), ar9170,
> zd1211rw (if possible), rt2800usb/pci.
For ath5k see
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=55ee82b500551f80720de57a00d2990d56cf08a8
^ permalink raw reply
* [PATCH] libertas: fix 8686 firmware loading regression in 96021f096e5178582af296a2fbb6df7dbd6b695c
From: Dan Williams @ 2010-04-28 19:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Steve deRosier, Alagu Sankar
In-Reply-To: <1272413690.32717.10.camel@localhost.localdomain>
The 'ready' condition was incorrectly evaluated which sometimes lead to
failures loading the second-stage firmware on 8686 devices.
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index 13dfeda..64dd345 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -324,7 +324,9 @@ static int if_sdio_wait_status(struct if_sdio_card *card, const u8 condition)
timeout = jiffies + HZ;
while (1) {
status = sdio_readb(card->func, IF_SDIO_STATUS, &ret);
- if (ret || (status & condition))
+ if (ret)
+ return ret;
+ if ((status & condition) == condition)
break;
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
^ permalink raw reply related
* 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
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