* [PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Vivek Natarajan @ 2010-04-23 7:10 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Ranga Rao Ravuri
If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
with WEP or TKIP, eventhough the received frame may be a CRC failed
corrupted frame.
Reported-by: Johan Hovold <johan.hovold@lundinova.se>
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
index cd953f6..025c31a 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
@@ -249,7 +249,7 @@ static const u32 ar5416Common[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8000010 },
+ { 0x00008264, 0x88000010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
index f06313d..dae7f33 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
@@ -793,7 +793,7 @@ static const u32 ar9280Common_9280_2[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -1963,7 +1963,7 @@ static const u32 ar9285Common_9285[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -3185,7 +3185,7 @@ static const u32 ar9287Common_9287_1_0[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -4973,7 +4973,7 @@ static const u32 ar9271Common_9271[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Luis R. Rodriguez @ 2010-04-23 7:22 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linville, linux-wireless, Ranga Rao Ravuri
In-Reply-To: <1272006625-6136-1-git-send-email-vnatarajan@atheros.com>
On Fri, Apr 23, 2010 at 12:10 AM, Vivek Natarajan
<vnatarajan@atheros.com> wrote:
> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
> with WEP or TKIP, eventhough the received frame may be a CRC failed
> corrupted frame.
>
> Reported-by: Johan Hovold <johan.hovold@lundinova.se>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
> Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
Is this a stable fix? If so please indicate. If not, please indicate why not :)
Luis
^ permalink raw reply
* [PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Vivek Natarajan @ 2010-04-23 7:26 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, stable, Ranga Rao Ravuri
If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
with WEP or TKIP, eventhough the received frame may be a CRC failed
corrupted frame.
Cc: stable@kernel.org
Reported-by: Johan Hovold <johan.hovold@lundinova.se>
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
index cd953f6..025c31a 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
@@ -249,7 +249,7 @@ static const u32 ar5416Common[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8000010 },
+ { 0x00008264, 0x88000010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
index f06313d..dae7f33 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
@@ -793,7 +793,7 @@ static const u32 ar9280Common_9280_2[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -1963,7 +1963,7 @@ static const u32 ar9285Common_9285[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -3185,7 +3185,7 @@ static const u32 ar9287Common_9287_1_0[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -4973,7 +4973,7 @@ static const u32 ar9271Common_9271[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
--
1.7.0.5
^ permalink raw reply related
* Re: update compat drivers,adpter can not be work,4 help.tks
From: Gábor Stefanik @ 2010-04-23 8:08 UTC (permalink / raw)
To: seco.wu; +Cc: linux-wireless
In-Reply-To: <t2qe4fca08d1004221720gc8551b6bq21fb043eb9128f56@mail.gmail.com>
On Fri, Apr 23, 2010 at 2:20 AM, SECO <secowu@gmail.com> wrote:
> & this is the full log
>
>
> ./scripts/gen-compat-autoconf.sh config.mk > include/linux/compat_autoconf.h
> make -C /lib/modules/2.6.30.9/build M=/root/compat-wireless-2.6.34-rc4 modules
> make[1]: Entering directory `/usr/src/linux-source-2.6.30.9'
>
> WARNING: Symbol version dump /usr/src/linux-source-2.6.30.9/Module.symvers
> is missing; modules will have no dependencies and modversions.
>
> CC [M] /root/compat-wireless-2.6.34-rc4/compat/main.o
> ....
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/mac80211_hwsim.o
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/mac80211_hwsim.c: In funct
> ion ‘__check_fake_hw_scan’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/mac80211_hwsim.c:37: warni
> ng: return from incompatible pointer type
> ...
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/main.c: In
> function ‘b43_request_firmware’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/main.c:2271:
> warning: format not a string literal and no format
> arguments
> ...
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:442:
> warning: ‘b43_nphy_rx_cal_phy_cleanup’ defined but
> not used
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:465:
> warning: ‘b43_nphy_rx_cal_phy_setup’ defined but n
> ot used
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:1462:
> warning: ‘b43_nphy_bphy_init’ defined but not use
> d
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c: In
> function ‘b43_nphy_spur_workaround’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:739:
> warning: ‘channel’ may be used uninitialized in th
> is function
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c: In
> function ‘b43_nphy_cal_tx_iq_lo’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:2519:
> warning: ‘last’ may be used uninitialized in this
> function
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c: In
> function ‘b43_nphy_rev2_cal_rx_iq’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:2774:
> warning: ‘cur_hpf2’ may be used uninitialized in
> this function
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/b43/phy_n.c:2774:
> warning: ‘cur_hpf1’ may be used uninitialized in
> this function
> ...
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/ipw2x00/libipw_wx.c:
> In function ‘libipw_wx_set_encodeext’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/ipw2x00/libipw_wx.c:623:
> warning: format not a string literal and n
> o format arguments
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/ipw2x00/libipw_geo.o
> ...
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-5000.o
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-5000.c:
> In function ‘iwl5000_gain_computation’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-5000.c:189:
> warning: comparison of distinct pointer typ
> es lacks a cast
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-6000.o
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-1000.o
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-core.o
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-core.c:
> In function ‘__check_bt_coex_active’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-core.c:68:
> warning: return from incompatible pointer ty
> pe
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-eeprom.o
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-hcmd.o
> CC [M] /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-power.o
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-power.c:
> In function ‘__check_no_sleep_autoadjust’:
> /root/compat-wireless-2.6.34-rc4/drivers/net/wireless/iwlwifi/iwl-power.c:58:
> warning: return from incompatible pointer t
> ype
> ...
> CC [M] /root/compat-wireless-2.6.34-rc4/net/bluetooth/hidp/core.o
> /root/compat-wireless-2.6.34-rc4/net/bluetooth/hidp/core.c: In
> function ‘hidp_setup_hid’:
> /root/compat-wireless-2.6.34-rc4/net/bluetooth/hidp/core.c:872:
> warning: assignment from incompatible pointer type
> CC [M] /root/compat-wireless-2.6.34-rc4/net/bluetooth/hidp/sock.o
> ...
> CC [M] /root/compat-wireless-2.6.34-rc4/net/mac80211/main.o
> /root/compat-wireless-2.6.34-rc4/net/mac80211/main.c: In function
> ‘__check_ieee80211_disable_40mhz_24ghz’:
> /root/compat-wireless-2.6.34-rc4/net/mac80211/main.c:39: warning:
> return from incompatible pointer type
> CC [M] /root/compat-wireless-2.6.34-rc4/net/mac80211/status.o
>
> sudo make install
> ...
> make -C /lib/modules/2.6.30.9/build M=/root/compat-wireless-2.6.34-rc4 modules
> make[1]: Entering directory `/usr/src/linux-source-2.6.30.9'
>
> WARNING: Symbol version dump /usr/src/linux-source-2.6.30.9/Module.symvers
> is missing; modules will have no dependencies and modversions.
>
> .......
> INSTALL /root/compat-wireless-2.6.34-rc4/net/wireless/lib80211_crypt_wep.ko
> DEPMOD 2.6.30.9
> make[1]: Leaving directory `/usr/src/linux-source-2.6.30.9'
> Updating Ubuntu's initramfs for 2.6.31-wl under /boot/ ...
> Cannot find /lib/modules/2.6.31-wl
> Will now run update-grub to ensure grub will find the new initramfs ...
> Searching for GRUB installation directory ... found: /boot/grub
> Searching for default file ... found: /boot/grub/default
> Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
> Searching for splash image ... found: /boot/grub/splash.xpm.gz
> Found kernel: /boot/vmlinuz-2.6.30.9
> Found kernel: /boot/memtest86+.bin
> Updating /boot/grub/menu.lst ... done
>
> depmod will prefer updates/ over kernel/ -- OK!
>
> Currently detected wireless subsystem modules:
>
> /lib/modules/2.6.30.9/updates/net/mac80211/mac80211.ko
> /lib/modules/2.6.30.9/updates/net/wireless/cfg80211.ko
> /lib/modules/2.6.30.9/updates/net/wireless/lib80211.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/adm8211.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ath/ar9170/ar9170usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/at76c50x-usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ath/ath.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ath/ath5k/ath5k.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ath/ath9k/ath9k.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/b43/b43.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/b43legacy/b43legacy.ko
> /lib/modules/2.6.30.9/updates/drivers/net/usb/cdc_ether.ko
> /lib/modules/2.6.30.9/updates/drivers/misc/eeprom/eeprom_93cx6.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ipw2x00/ipw2100.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ipw2x00/ipw2200.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/iwlwifi/iwl3945.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/iwlwifi/iwlagn.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/iwlwifi/iwlcore.ko
> /lib/modules/2.6.30.9/updates/net/wireless/lib80211_crypt_ccmp.ko
> /lib/modules/2.6.30.9/updates/net/wireless/lib80211_crypt_tkip.ko
> /lib/modules/2.6.30.9/updates/net/wireless/lib80211_crypt_wep.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/libertas/libertas.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/libertas/libertas_cs.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/libertas/libertas_sdio.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/libertas_tf/libertas_tf.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/libertas_tf/libertas_tf_usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/ipw2x00/libipw.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/mac80211_hwsim.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/mwl8k.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/p54/p54common.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/p54/p54pci.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/p54/p54usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/usb/rndis_host.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rndis_wlan.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt2400pci.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt2500pci.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt2500usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt2x00lib.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt2x00pci.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt2x00usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt61pci.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rt2x00/rt73usb.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rtl818x/rtl8180.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/rtl818x/rtl8187.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/libertas/usb8xxx.ko
> /lib/modules/2.6.30.9/updates/drivers/net/usb/usbnet.ko
> /lib/modules/2.6.30.9/updates/drivers/net/wireless/zd1211rw/zd1211rw.ko
>
> Currently detected bluetooth subsystem modules:
>
> /lib/modules/2.6.30.9/updates/net/bluetooth/sco.ko
> /lib/modules/2.6.30.9/updates/net/bluetooth/l2cap.ko
> /lib/modules/2.6.30.9/updates/net/bluetooth/hidp/hidp.ko
> /lib/modules/2.6.30.9/updates/net/bluetooth/rfcomm/rfcomm.ko
> /lib/modules/2.6.30.9/updates/net/bluetooth/bnep/bnep.ko
> /lib/modules/2.6.30.9/updates/drivers/bluetooth/btusb.ko
> /lib/modules/2.6.30.9/updates/net/bluetooth/bluetooth.ko
>
> Now run:
>
> sudo make unload to unload both wireless and bluetooth modules
> sudo make wlunload to unload wireless modules
> sudo make btunload to unload bluetooth modules
>
> And then load the wireless or bluetooth module you need. If unsure reboot.
> Alternatively use sudo make load/wlload/btload to load modules
>
> root@bt:~/compat-wireless-2.6.34-rc4#
> root@bt:~/compat-wireless-2.6.34-rc4# sudo make unload
> Stoping bluetooth service..
> Stopping bluetooth: bluetoothd.
> * bluetooth is not running.
> Unloading ar9170usb...
> Unloading rfcomm...
> Unloading btusb...
> root@bt:~/compat-wireless-2.6.34-rc4# sudo make wlunload
> root@bt:~/compat-wireless-2.6.34-rc4# sudo make btunload
> Stoping bluetooth service..
> Stopping bluetooth: bluetoothd.
> * bluetooth is not running.
> Unloading rfcomm...
> root@bt:~/compat-wireless-2.6.34-rc4#
> root@bt:~/compat-wireless-2.6.34-rc4# sudo make load
> Stoping bluetooth service..
> Stopping bluetooth: bluetoothd.
> * bluetooth is not running.
> Unloading rfcomm...
> Loading ipw2100...
> Loading ipw2200...
> Loading libertas_cs...
> Loading usb8xxx...
> Loading p54pci...
> Loading p54usb...
> Loading adm8211...
> Loading zd1211rw...
> Loading rtl8180...
> Loading rtl8187...
> Loading p54pci...
> Loading p54usb...
> Loading iwl3945...
> Loading iwlagn...
> Loading ath...
> Loading ar9170usb...
> Loading rtl8180...
> Loading rtl8187...
> Loading rt2400pci...
> Loading rt2500pci...
> Loading rt61pci...
> Loading rt2500usb...
> Loading rt73usb...
> Loading rndis_wlan...
> Loading at76_usb...
> FATAL: Module at76_usb not found.
> Loading mwl8k...
> Loading mac80211_hwsim...
> Loading at76c50x_usb...
> Loading bluetooth...
> Loading btusb...
> Loading l2cap...
> Loading sco...
> Loading hidp...
> Loading rfcomm...
> Loading bnep...
> Module ath_pci not detected -- this is fine
> ath5k loaded successfully
> ath9k loaded successfully
> Module bcm43xx not detected -- this is fine
> Module wl not detected -- this is fine
> FATAL: Error inserting b43
> (/lib/modules/2.6.30.9/updates/drivers/net/wireless/b43/b43.ko):
> Unknown symbol in module, or unknown parameter (see dmesg)
> b43 loaded successfully
> b43legacy loaded successfully
> Starting bluetooth service..
> Starting bluetooth: bluetoothd.
> bluetooth is running.
>
>
> 2010/4/23, SECO <secowu@gmail.com>:
>> Hi,Sir.
>>
>> I use BT4,after Updated drivers, the original adpter bcm4311 can not be
>> work.
>> Not mention WN721 and WN821N .
>> & log here
>>
>> root@bt:~# ln -s /usr/src/linux /lib/modules/2.6.30.9/build
>> root@bt:~# wget
>> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2010-04-21.tar.bz2
>> --2010-04-22 21:21:31--
>> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2010-04-21.tar.bz2
>> Resolving wireless.kernel.org... 78.46.109.217
>> Connecting to wireless.kernel.org|78.46.109.217|:80... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 2424098 (2.3M) [application/octet-stream]
>> Saving to: `compat-wireless-2010-04-21.tar.bz2'
>>
>> 100%[==================================================================================================================>]
>> 2,424,098 44.0K/s in 56s
>>
>> 2010-04-22 21:22:29 (42.1 KB/s) - `compat-wireless-2010-04-21.tar.bz2'
>> saved [2424098/2424098]
>>
>> root@bt:~# tar -xf compat-wireless-2010-04-21.tar.bz2
>> root@bt:~# cd compat-wireless-2010-04-21.tar.bz22.make & make install
>>
>> Code:
>> oot@bt:~/compat-wireless-2010-04-21# sudo make && sudo make install
>> make -C /lib/modules/2.6.30.9/build M=/root/compat-wireless-2010-04-21
>> modules
>> make[1]: Entering directory `/usr/src/linux-source-2.6.30.9'
>> ....
>> CC [M] /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/main.o
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/main.c: In
>> function ‘b43_request_firmware’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/main.c:2271:
>> warning: format not a string literal and no format arguments
>> ....
>> root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:465:
>> warning: ‘b43_nphy_rx_cal_phy_cleanup’ defined but not used
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:488:
>> warning: ‘b43_nphy_rx_cal_phy_setup’ defined but not used
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:1574:
>> warning: ‘b43_nphy_bphy_init’ defined but not used
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c: In
>> function ‘b43_nphy_set_chanspec’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:3376:
>> warning: ‘tabent_r3’ may be used uninitialized in this function
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c: In
>> function ‘b43_nphy_cal_tx_iq_lo’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:2631:
>> warning: ‘last’ may be used uninitialized in this function
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c: In
>> function ‘b43_nphy_rev2_cal_rx_iq’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:2886:
>> warning: ‘cur_hpf2’ may be used uninitialized in this function
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/phy_n.c:2886:
>> warning: ‘cur_hpf1’ may be used uninitialized in this function
>> ...
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/xmit.c: In
>> function ‘b43_rx’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43/xmit.c:613:
>> warning: ‘noise’ is deprecated (declared at
>> /root/compat-wireless-2010-04-21/include/net/mac80211.h:564)
>> ...
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43legacy/xmit.c:
>> In function ‘b43legacy_rx’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/b43legacy/xmit.c:551:
>> warning: ‘noise’ is deprecated (declared at
>> /root/compat-wireless-2010-04-21/include/net/mac80211.h:564)
>> ...
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/ipw2x00/libipw_wx.c:
>> In function ‘libipw_wx_set_encodeext’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/ipw2x00/libipw_wx.c:623:
>> warning: format not a string literal and no format arguments
>> ...
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c:
>> In function ‘iwlagn_gain_computation’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c:145:
>> warning: comparison of distinct pointer types lacks a cast
>> ...
>> root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-core.c:
>> In function ‘__check_bt_coex_active’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-core.c:68:
>> warning: return from incompatible pointer type
>> CC [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-eeprom.o
>> CC [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-hcmd.o
>> CC [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-power.o
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-power.c:
>> In function ‘__check_no_sleep_autoadjust’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/iwlwifi/iwl-power.c:58:
>> warning: return from incompatible pointer type
>> ....
>> root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/if_sdio.c:
>> In function ‘if_sdio_probe’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/if_sdio.c:948:
>> warning: unused variable ‘host’
>> CC [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/if_usb.o
>> LD [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/libertas.o
>> LD [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/usb8xxx.o
>> LD [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/libertas_cs.o
>> LD [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas/libertas_sdio.o
>> CC [M]
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas_tf/main.o
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas_tf/main.c:
>> In function ‘lbtf_rx’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/libertas_tf/main.c:513:
>> warning: ‘noise’ is deprecated (declared at
>> /root/compat-wireless-2010-04-21/include/net/mac80211.h:564)
>> CC [M] /root/compat-wireless-2010-
>> ...
>> root/compat-wireless-2010-04-21/drivers/net/wireless/p54/txrx.c: In
>> function ‘p54_rx_data’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/p54/txrx.c:353:
>> warning: ‘noise’ is deprecated (declared at
>> /root/compat-wireless-2010-04-21/include/net/mac80211.h:564)
>> ...
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/rt2x00/rt2x00dev.c:
>> In function ‘rt2x00lib_rxdone’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/rt2x00/rt2x00dev.c:438:
>> warning: ‘noise’ is deprecated (declared at
>> /root/compat-wireless-2010-04-21/include/net/mac80211.h:564)
>> ...
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/wl12xx/wl1251_rx.c:
>> In function ‘wl1251_rx_status’:
>> /root/compat-wireless-2010-04-21/drivers/net/wireless/wl12xx/wl1251_rx.c:81:
>> warning: ‘noise’ is deprecated (declared at
>> /root/compat-wireless-2010-04-21/include/net/mac80211.h:564)
>> ...
>> root/compat-wireless-2010-04-21/net/bluetooth/hidp/core.c: In function
>> ‘hidp_setup_hid’:
>> /root/compat-wireless-2010-04-21/net/bluetooth/hidp/core.c:872:
>> warning: assignment from incompatible pointer type
>> ....
>> /root/compat-wireless-2010-04-21/net/mac80211/main.c: In function
>> ‘__check_ieee80211_disable_40mhz_24ghz’:
>> /root/compat-wireless-2010-04-21/net/mac80211/main.c:37: warning:
>> return from incompatible pointer type
>> ...& download ar9271.fw form herer
>> '[PATCH 0/3] ath9k: add initial ar9271 support' - MARC
>>
>> Code:
>>
>> root@bt:~/compat-wireless-2010-04-21# make load
>> Stoping bluetooth service..
>> Stopping bluetooth: bluetoothd.
>> * bluetooth is not running.
>> Unloading b43...
>> Unloading ar9170usb...
>> Unloading lib80211...
>> FATAL: Module lib80211 is in use.
>> Unloading btusb...
>> Loading ipw2100...
>> Loading ipw2200...
>> Loading libertas_cs...
>> Loading usb8xxx...
>> Loading p54pci...
>> Loading p54usb...
>> Loading adm8211...
>> Loading zd1211rw...
>> Loading rtl8180...
>> Loading rtl8187...
>> Loading p54pci...
>> Loading p54usb...
>> Loading iwl3945...
>> Loading iwlagn...
>> Loading ath...
>> Loading ar9170usb...
>> Loading rtl8180...
>> Loading rtl8187...
>> Loading rt2400pci...
>> Loading rt2500pci...
>> Loading rt61pci...
>> Loading rt2500usb...
>> Loading rt73usb...
>> Loading rndis_wlan...
>> Loading at76_usb...
>> FATAL: Module at76_usb not found.
>> Loading mwl8k...
>> Loading mac80211_hwsim...
>> Loading at76c50x_usb...
>> Loading bluetooth...
>> Loading btusb...
>> Loading l2cap...
>> Loading sco...
>> Loading hidp...
>> Loading rfcomm...
>> Loading bnep...
>> Module ath_pci not detected -- this is fine
>> ath5k loaded successfully
>> ath9k loaded successfully
>> Module bcm43xx not detected -- this is fine
>> Disabling wl ... [OK] Module disabled:
>> /lib/modules/2.6.30.9/kernel/net/wireless/wl.ko
>> FATAL: Error inserting b43
>> (/lib/modules/2.6.30.9/updates/drivers/net/wireless/b43/b43.ko):
>> Unknown symbol in module, or unknown parameter (see dmesg)
>> b43 loaded successfully
>> b43legacy loaded successfully
>> Starting bluetooth service..
>> Starting bluetooth: bluetoothd.
>> bluetooth is running.
>> root@bt:~/compat-wireless-2010-04-21# ifconfig
>> eth0 Link encap:Ethernet HWaddr 00:2a:4b:18:68:99
>> UP BROADCAST MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>> Interrupt:16
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:16436 Metric:1
>> RX packets:218 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:218 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:10928 (10.9 KB) TX bytes:10928 (10.9 KB)
>>
>> wlan0 Link encap:Ethernet HWaddr 02:01:20:00:60:00
>> UP BROADCAST MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>>
>> root@bt:~/compat-wireless-2010-04-21# iwconfig
>> lo no wireless extensions.
>>
>> eth0 no wireless extensions.
>>
>> wlan0 IEEE 802.11abgn Mode:Managed Access Point: Not-Associated
>> Tx-Power=20 dBm
>> Retry long limit:7 RTS thr:off Fragment thr:off
>> Encryption key:off
>> Power Management:off
>>
>> wlan1 IEEE 802.11abgn Mode:Managed Access Point: Not-Associated
>> Tx-Power=0 dBm
>> Retry long limit:7 RTS thr:off Fragment thr:off
>> Encryption key:off
>> Power Management:off
>>
>> hwsim0 no wireless extensions.
>>
>> pan0 no wireless extensions.
>>
>> root@bt:~/compat-wireless-2010-04-21# ifconfig wlan0 up
>> root@bt:~/compat-wireless-2010-04-21# iwlist wlan0 scan
>> wlan0 No scan results
>>
>> root@bt:~/compat-wireless-2010-04-21# iwlist wlan1 scan
>> wlan1 Interface doesn't support scanning : Network is down
>>
>> root@bt:~/compat-wireless-2010-04-21# ifconfig wlan1 up
>> root@bt:~/compat-wireless-2010-04-21# iwlist wlan1 scan
>> wlan1 No scan results
>> root@bt:~/compat-wireless-2010-04-21/scripts# ./wlload.sh
>> Loading ipw2100...
>> Loading ipw2200...
>> Loading libertas_cs...
>> Loading usb8xxx...
>> Loading p54pci...
>> Loading p54usb...
>> Loading adm8211...
>> Loading zd1211rw...
>> Loading rtl8180...
>> Loading rtl8187...
>> Loading p54pci...
>> Loading p54usb...
>> Loading iwl3945...
>> Loading iwlagn...
>> Loading ath...
>> Loading ar9170usb...
>> Loading rtl8180...
>> Loading rtl8187...
>> Loading rt2400pci...
>> Loading rt2500pci...
>> Loading rt61pci...
>> Loading rt2500usb...
>> Loading rt73usb...
>> Loading rndis_wlan...
>> Loading at76_usb...
>> FATAL: Module at76_usb not found.
>> Loading mwl8k...
>> Loading mac80211_hwsim...
>> Loading at76c50x_usb...
>> Module ath_pci not detected -- this is fine
>> ath5k loaded successfully
>> ath9k loaded successfully
>> Module bcm43xx not detected -- this is fine
>> Module wl not detected -- this is fine
>> FATAL: Error inserting b43
>> (/lib/modules/2.6.30.9/updates/drivers/net/wireless/b43/b43.ko):
>> Unknown symbol in module, or unknown parameter (see dmesg)
Please post your dmesg output too.
>> b43 loaded successfully
>> b43legacy loaded successfully
>> root@bt:~/compat-wireless-2010-04-21# rebootbcm4311 can not be work
>> after update comapt-wireless u nder bt4 final.
>> Last edited by Archangel-Amael; Today at 02:49 PM.
>> Edit Post Reply Reply With Quote
>> --------------------------------------------------------------------------------
>> --
>> Best Regards
>> --------------------
>> SECO
>>
>> --------------------------------------------------------------------------------
>> This information in this e-mail is confidential and may well also be
>> legally privileged. It is intended solely for the addressee. If you
>> have received it in error, you are on notice of its status. Please
>> notify us immediately and then destroy this message. Please do not
>> copy it or use it for any purposes, or disclose its contents to any
>> other person: to do so could be a breach of confidence. Thank you for
>> your co-operation.
>> --------------------------------------------------------------------------------
>>
>
>
> --
> Best Regards
> --------------------
> SECO
>
> --------------------------------------------------------------------------------
> This information in this e-mail is confidential and may well also be
> legally privileged. It is intended solely for the addressee. If you
> have received it in error, you are on notice of its status. Please
> notify us immediately and then destroy this message. Please do not
> copy it or use it for any purposes, or disclose its contents to any
> other person: to do so could be a breach of confidence. Thank you for
> your co-operation.
> --------------------------------------------------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Walter Goldens @ 2010-04-23 8:46 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo van Doorn, linux-wireless, users
In-Reply-To: <4BD0B6BD.50509@gmail.com>
> > The problem as I recall first occurred in late January
> or some time in February when someone decided to
> remove large portion of the VIDs from the code because of
> driver collisions and I suppose the purpose of it was to
> reshuffle VID tables and insert some sort of order. Since
> then, compat-wireless does not automatically provide drivers
> for the rt307x via rt2800usb. To this point, only manual
> modification and inserting of the VIDs above solves the
> problem.
> >
> > I'm a 100% certain of this. Even if your cards have
> different VIDs /not 148f:3070/, just install compat-wireless
> with enabled rt307X support and see if "modinfo rt2800usb
> |grep 3070" returns something. Then you'll be able to verify
> my reports.
> >
>
> As I mentioned, I am not experiencing this. See attached
> the modinfo output for the modules that I built with a clean
> compat-wireless package.
>
> The only way I can explain this is that on your system, for
> some reason, changes to config.mk are not picked up by the
> build system.
>
> Can you try removing the include/linux/compat_autoconf.h
> file (from the root of the compat-wireless tree), and then
> run a make clean, followed by a make.
>
> ---
> Gertjan.
Unfortunately, removing this file changes nothing. The rt2800usb still doesn't pick up the 148f:3070 VID as modinfo would show. That is with enabled rt307x support in config.mk and removed compat_autoconf.h in the compat directory. I'm on a Ubuntu 9.10 / 2.6.31-20 kernel. The problem appears to be deeper that I thought.
I don't mind manually modifying VID table to enable support for my devices, but this would mean a large number of users won't be able to take advantage of the new code via compat-wireless. I'm puzzled how results differ, you appear to be testing it on Fedora system with .2.6.32 and Ubuntu 2.6.31 fails. I'm running out of explanations.
Walter.
^ permalink raw reply
* Re: bug report: potential ERR_PTR dereference in iwm_debugfs_init()
From: Dan Carpenter @ 2010-04-23 11:43 UTC (permalink / raw)
To: Zhu Yi; +Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org
In-Reply-To: <1271990911.14773.24.camel@debian>
On Fri, Apr 23, 2010 at 10:48:31AM +0800, Zhu Yi wrote:
> On Thu, 2010-04-22 at 17:59 +0800, Dan Carpenter wrote:
> > Hi Zhu Yi,
> >
> > This is a Smatch bug that has me a little puzzled.
> >
> > drivers/net/wireless/iwmc3200wifi/debugfs.c +447 iwm_debugfs_init(26)
> > warn: 'iwm->dbg.devdir' dereferencing possible ERR_PTR()
> >
> > 440 iwm->dbg.devdir = debugfs_create_dir(devdir, iwm->dbg.rootdir);
> > 441 result = PTR_ERR(iwm->dbg.devdir);
> > 442 if (IS_ERR(iwm->dbg.devdir) && (result != -ENODEV)) {
> > 443 IWM_ERR(iwm, "Couldn't create devdir: %d\n", result);
> > 444 goto error;
> > 445 }
> > 446
> > 447 iwm->dbg.dbgdir = debugfs_create_dir("debug", iwm->dbg.devdir);
> >
> > It looks like "iwm->dbg.devdir" could be ERR_PTR(-ENODEV) on line 447 and
> > that would cause a problem inside debugfs_create_dir(). But at the same
> > time -ENODEV was deliberately singled out as OK from other possible errors
> > that debugfs_create_dir() can return.
>
> We take -ENODEV for debugfs_create_dir if CONFIG_DEBUG_FS is not
> enabled. We returns 0 deliberately in this case for rootdir create. I
> agree we don't need to check it for the subdirs like we did now. But I
> found lots of code don't even check (or don't use IS_ERR to check) the
> return value of debugfs_create_dir. Maybe that's more problematic?
Ah. Thanks for the explanation.
The bit that was problematic in this code for me is that passing
ERR_PTR(-ENODEV) to debugfs_create_dir() on line 447 will cause an oops.
But, as you point out, the check on line 442 is never true because we
already established that debugfs is enabled.
Couldn't we just check "if (debugfs_initialized()) { " and remove all
the ERR_PTR checking?
If you would like I can send a patch to do this.
regards,
dan carpenter
^ permalink raw reply
* Re: bug report: potential ERR_PTR dereference in iwm_debugfs_init()
From: Johannes Berg @ 2010-04-23 12:03 UTC (permalink / raw)
To: Dan Carpenter
Cc: Zhu Yi, Intel Linux Wireless, linux-wireless@vger.kernel.org
In-Reply-To: <20100423114358.GD29093@bicker>
On Fri, 2010-04-23 at 13:43 +0200, Dan Carpenter wrote:
> > > This is a Smatch bug that has me a little puzzled.
> > >
> > > drivers/net/wireless/iwmc3200wifi/debugfs.c +447 iwm_debugfs_init(26)
> > > warn: 'iwm->dbg.devdir' dereferencing possible ERR_PTR()
> > >
> > > 440 iwm->dbg.devdir = debugfs_create_dir(devdir, iwm->dbg.rootdir);
> > > 441 result = PTR_ERR(iwm->dbg.devdir);
> > > 442 if (IS_ERR(iwm->dbg.devdir) && (result != -ENODEV)) {
> > > 443 IWM_ERR(iwm, "Couldn't create devdir: %d\n", result);
> > > 444 goto error;
> > > 445 }
> > > 446
> > > 447 iwm->dbg.dbgdir = debugfs_create_dir("debug", iwm->dbg.devdir);
> > >
> > > It looks like "iwm->dbg.devdir" could be ERR_PTR(-ENODEV) on line 447 and
> > > that would cause a problem inside debugfs_create_dir(). But at the same
> > > time -ENODEV was deliberately singled out as OK from other possible errors
> > > that debugfs_create_dir() can return.
> >
> > We take -ENODEV for debugfs_create_dir if CONFIG_DEBUG_FS is not
> > enabled. We returns 0 deliberately in this case for rootdir create. I
> > agree we don't need to check it for the subdirs like we did now. But I
> > found lots of code don't even check (or don't use IS_ERR to check) the
> > return value of debugfs_create_dir. Maybe that's more problematic?
>
> Ah. Thanks for the explanation.
>
> The bit that was problematic in this code for me is that passing
> ERR_PTR(-ENODEV) to debugfs_create_dir() on line 447 will cause an oops.
> But, as you point out, the check on line 442 is never true because we
> already established that debugfs is enabled.
I don't think so. See, that function will only return -ENODEV when
debugfs is not compiled into the kernel, and in that case the argument
to debugfs_create_dir is never used anyway.
johannes
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: disable HT40 for now as it causes reception problems
From: Helmut Schaa @ 2010-04-23 13:05 UTC (permalink / raw)
To: John Linville
Cc: Ivo van Doorn, Gertjan van Wingerde, linux-wireless,
rt2x00 Users List
Disable HT40 support for now as it causes rx problems with HT40 capable
11n APs (when mac80211 enables HT40, rx is completely disfunctional).
Once the rt2800 HT code is capable of using HT40 we should enable the
flag again.
I only tested this patch with a rt305x SoC device, nevertheless the
patch disables HT40 also on PCI and USB rt2800 devices.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
Using this patch I was able to associate a rt305x SoC device with my 11n
capable AP using WPA and the connection basically works although I see lots
of retried frames when sniffing the wireless traffic.
If someone already had success with rt2800 and HT40 capable APs we should
consider to only conditionally unset the HT40 flag for 305x SoC devices.
drivers/net/wireless/rt2x00/rt2800lib.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 2648f31..aa02ff6 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2318,8 +2318,11 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
else
spec->ht.ht_supported = false;
+ /*
+ * Don't set IEEE80211_HT_CAP_SUP_WIDTH_20_40 for now as it causes
+ * reception problems with HT40 capable 11n APs
+ */
spec->ht.cap =
- IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
IEEE80211_HT_CAP_GRN_FLD |
IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40 |
--
1.6.4.2
^ permalink raw reply related
* [PATCH] rt2x00: rt2800: use tx_power2 in rt2800_config_channel_rf3xxx
From: Helmut Schaa @ 2010-04-23 13:54 UTC (permalink / raw)
To: John Linville; +Cc: Ivo van Doorn, Gertjan van Wingerde, linux-wireless
Get closer to what the ralink driver does by setting the rf register 13
to tx_power2 during channel switch.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
Just found that difference between rt2x00 and the ralink driver.
However I couldn't see any obvious improvements. So, this change
is mostly for completeness.
drivers/net/wireless/rt2x00/rt2800.h | 5 +++++
drivers/net/wireless/rt2x00/rt2800lib.c | 5 +++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index ec89372..1c59dc6 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -1566,6 +1566,11 @@ struct mac_iveiv_entry {
#define RFCSR12_TX_POWER FIELD8(0x1f)
/*
+ * RFCSR 13:
+ */
+#define RFCSR13_TX_POWER FIELD8(0x1f)
+
+/*
* RFCSR 15:
*/
#define RFCSR15_TX_LO2_EN FIELD8(0x08)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index aa02ff6..3ee9882 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -794,6 +794,11 @@ static void rt2800_config_channel_rf3xxx(struct rt2x00_dev *rt2x00dev,
TXPOWER_G_TO_DEV(info->tx_power1));
rt2800_rfcsr_write(rt2x00dev, 12, rfcsr);
+ rt2800_rfcsr_read(rt2x00dev, 13, &rfcsr);
+ rt2x00_set_field8(&rfcsr, RFCSR13_TX_POWER,
+ TXPOWER_G_TO_DEV(info->tx_power2));
+ rt2800_rfcsr_write(rt2x00dev, 13, rfcsr);
+
rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
rt2x00_set_field8(&rfcsr, RFCSR23_FREQ_OFFSET, rt2x00dev->freq_offset);
rt2800_rfcsr_write(rt2x00dev, 23, rfcsr);
--
1.6.4.2
^ permalink raw reply related
* Re: ath5k misbehaving affecting other kernel parts unrelated?
From: John W. Linville @ 2010-04-23 13:48 UTC (permalink / raw)
To: Pedro Francisco; +Cc: linux-kernel, linux-wireless, me, mickflemm
In-Reply-To: <201004230806.13628.pedrogfrancisco@gmail.com>
On Fri, Apr 23, 2010 at 08:06:13AM +0100, Pedro Francisco wrote:
> Greetings!
>
> Is it possible a faulty ath5k module to affect diverse parts of kernel causing
> different oopses to happen referencing things as different as cdrom_ioctl,
> find_vma, i915_gem_object_get_pages, get_vfs_caps_from_disk,
> warn_slowpath_common (ath5k_tasklet_rx), proc_lookup_de and
> _spin_lock(ext4_getattr) [soft lookup]?
>
> The task in which such errors happen is capturing packets with kismet during
> the night. The errors aren't easy to create, sometimes they've already
> happened when I check the computer in the morning and sometimes they require
> stirring up the computer a bit such as starting X.
>
> I memtested the machine during 7h and no error was detected.
>
> I've been trying different kernels but main one is 2.6.32-21-generic, Ubuntu
> flavour, with linux-backports-modules-wireless-lucid-generic installed. I would
> use 2.6.34-rc5 vanilla if shutdown and suspend worked ;)
>
> As such:
> a) is it "normal"? I thought modules were somewhat isolated these days.
> b) any advices for debugging? I've yet to have two oopses that are similar....
It is certainly possible -- improper setup of DMA could be scribbling
over memory that doesn't belong to ath5k. That sort of thing can be
ugly to track-down...
You mentioned Kismet. Do you experience this sort of problem when
using ath5k for "normal" purposes (e.g. browsing the web)? Or only
when using it to monitor the network?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: disable HT40 for now as it causes reception problems
From: Gertjan van Wingerde @ 2010-04-23 15:21 UTC (permalink / raw)
To: Helmut Schaa
Cc: John Linville, Ivo van Doorn, linux-wireless, rt2x00 Users List
In-Reply-To: <201004231505.29689.helmut.schaa@googlemail.com>
On 04/23/10 15:05, Helmut Schaa wrote:
> Disable HT40 support for now as it causes rx problems with HT40 capable
> 11n APs (when mac80211 enables HT40, rx is completely disfunctional).
>
> Once the rt2800 HT code is capable of using HT40 we should enable the
> flag again.
>
> I only tested this patch with a rt305x SoC device, nevertheless the
> patch disables HT40 also on PCI and USB rt2800 devices.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
I can confirm that this also helps for PCI and USB devices.
With this patch applied all my rt28xx and rt30xx based devices starting working correctly.
So, definately,
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
>
> Using this patch I was able to associate a rt305x SoC device with my 11n
> capable AP using WPA and the connection basically works although I see lots
> of retried frames when sniffing the wireless traffic.
>
> If someone already had success with rt2800 and HT40 capable APs we should
> consider to only conditionally unset the HT40 flag for 305x SoC devices.
>
> drivers/net/wireless/rt2x00/rt2800lib.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 2648f31..aa02ff6 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -2318,8 +2318,11 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> else
> spec->ht.ht_supported = false;
>
> + /*
> + * Don't set IEEE80211_HT_CAP_SUP_WIDTH_20_40 for now as it causes
> + * reception problems with HT40 capable 11n APs
> + */
> spec->ht.cap =
> - IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
> IEEE80211_HT_CAP_GRN_FLD |
> IEEE80211_HT_CAP_SGI_20 |
> IEEE80211_HT_CAP_SGI_40 |
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800: use tx_power2 in rt2800_config_channel_rf3xxx
From: Gertjan van Wingerde @ 2010-04-23 15:25 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, Ivo van Doorn, linux-wireless
In-Reply-To: <201004231554.43474.helmut.schaa@googlemail.com>
On 04/23/10 15:54, Helmut Schaa wrote:
> Get closer to what the ralink driver does by setting the rf register 13
> to tx_power2 during channel switch.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Good catch.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> ---
>
> Just found that difference between rt2x00 and the ralink driver.
> However I couldn't see any obvious improvements. So, this change
> is mostly for completeness.
>
> drivers/net/wireless/rt2x00/rt2800.h | 5 +++++
> drivers/net/wireless/rt2x00/rt2800lib.c | 5 +++++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
> index ec89372..1c59dc6 100644
> --- a/drivers/net/wireless/rt2x00/rt2800.h
> +++ b/drivers/net/wireless/rt2x00/rt2800.h
> @@ -1566,6 +1566,11 @@ struct mac_iveiv_entry {
> #define RFCSR12_TX_POWER FIELD8(0x1f)
>
> /*
> + * RFCSR 13:
> + */
> +#define RFCSR13_TX_POWER FIELD8(0x1f)
> +
> +/*
> * RFCSR 15:
> */
> #define RFCSR15_TX_LO2_EN FIELD8(0x08)
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index aa02ff6..3ee9882 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -794,6 +794,11 @@ static void rt2800_config_channel_rf3xxx(struct rt2x00_dev *rt2x00dev,
> TXPOWER_G_TO_DEV(info->tx_power1));
> rt2800_rfcsr_write(rt2x00dev, 12, rfcsr);
>
> + rt2800_rfcsr_read(rt2x00dev, 13, &rfcsr);
> + rt2x00_set_field8(&rfcsr, RFCSR13_TX_POWER,
> + TXPOWER_G_TO_DEV(info->tx_power2));
> + rt2800_rfcsr_write(rt2x00dev, 13, rfcsr);
> +
> rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
> rt2x00_set_field8(&rfcsr, RFCSR23_FREQ_OFFSET, rt2x00dev->freq_offset);
> rt2800_rfcsr_write(rt2x00dev, 23, rfcsr);
^ permalink raw reply
* Re: ath5k misbehaving affecting other kernel parts unrelated?
From: me @ 2010-04-23 16:37 UTC (permalink / raw)
To: John W. Linville; +Cc: Pedro Francisco, linux-kernel, linux-wireless, mickflemm
In-Reply-To: <20100423134823.GB5004@tuxdriver.com>
On Fri, Apr 23, 2010 at 09:48:23AM -0400, John W. Linville wrote:
> > a) is it "normal"? I thought modules were somewhat isolated these days.
> > b) any advices for debugging? I've yet to have two oopses that are similar....
Advice for debugging: turn on slub/slab debug options, and possibly
kmemcheck. kmemcheck was very helpful for me last time I had such
a corruption issue.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k misbehaving affecting other kernel parts unrelated?
From: Maciej Żenczykowski @ 2010-04-23 16:43 UTC (permalink / raw)
To: me
Cc: John W. Linville, Pedro Francisco, linux-kernel, linux-wireless,
mickflemm
In-Reply-To: <20100423163703.GB11112@hash.localnet>
Do you have more than ~2.5-3.5GB of ram (enough to make some ram
non-32-bit-DMA-accessible) with swiotlb enabled,
if such are you seeing "DMA: Out of SW-IOMMU space" kernel messages?
On Fri, Apr 23, 2010 at 09:37, <me@bobcopeland.com> wrote:
> On Fri, Apr 23, 2010 at 09:48:23AM -0400, John W. Linville wrote:
>> > a) is it "normal"? I thought modules were somewhat isolated these days.
>> > b) any advices for debugging? I've yet to have two oopses that are similar....
>
> Advice for debugging: turn on slub/slab debug options, and possibly
> kmemcheck. kmemcheck was very helpful for me last time I had such
> a corruption issue.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800: use tx_power2 in rt2800_config_channel_rf3xxx
From: Ivo van Doorn @ 2010-04-23 18:01 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, Gertjan van Wingerde, linux-wireless
In-Reply-To: <201004231554.43474.helmut.schaa@googlemail.com>
On Friday 23 April 2010, Helmut Schaa wrote:
> Get closer to what the ralink driver does by setting the rf register 13
> to tx_power2 during channel switch.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: disable HT40 for now as it causes reception problems
From: Ivo van Doorn @ 2010-04-23 18:08 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Helmut Schaa, John Linville, linux-wireless, rt2x00 Users List
In-Reply-To: <4BD1BAF8.1060908@gmail.com>
On Friday 23 April 2010, Gertjan van Wingerde wrote:
> On 04/23/10 15:05, Helmut Schaa wrote:
> > Disable HT40 support for now as it causes rx problems with HT40 capable
> > 11n APs (when mac80211 enables HT40, rx is completely disfunctional).
> >
> > Once the rt2800 HT code is capable of using HT40 we should enable the
> > flag again.
> >
> > I only tested this patch with a rt305x SoC device, nevertheless the
> > patch disables HT40 also on PCI and USB rt2800 devices.
> >
> > Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>
> I can confirm that this also helps for PCI and USB devices.
> With this patch applied all my rt28xx and rt30xx based devices starting working correctly.
>
> So, definately,
>
> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
And also thanks for figuring this out, this at least gives a good starting
point for investigation for resolving the last issues. :)
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> > ---
> >
> > Using this patch I was able to associate a rt305x SoC device with my 11n
> > capable AP using WPA and the connection basically works although I see lots
> > of retried frames when sniffing the wireless traffic.
> >
> > If someone already had success with rt2800 and HT40 capable APs we should
> > consider to only conditionally unset the HT40 flag for 305x SoC devices.
> >
> > drivers/net/wireless/rt2x00/rt2800lib.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> > index 2648f31..aa02ff6 100644
> > --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> > +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> > @@ -2318,8 +2318,11 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
> > else
> > spec->ht.ht_supported = false;
> >
> > + /*
> > + * Don't set IEEE80211_HT_CAP_SUP_WIDTH_20_40 for now as it causes
> > + * reception problems with HT40 capable 11n APs
> > + */
> > spec->ht.cap =
> > - IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
> > IEEE80211_HT_CAP_GRN_FLD |
> > IEEE80211_HT_CAP_SGI_20 |
> > IEEE80211_HT_CAP_SGI_40 |
>
>
^ permalink raw reply
* [PATCH] ssb: Make bus registration failure not be silent
From: Larry Finger @ 2010-04-23 18:17 UTC (permalink / raw)
To: John W Linville, Michael Buesch; +Cc: b43-dev, linux-wireless
In kernel Bugzilla #15825, a case where routine ssb_bus_pcibus_register()
fails silently is reported. The cause for the failure is still being
investigated; however, the diagnosis would be easier if the failure
had been reported.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
This patch has low priority - 2.6.35. Whatever fixes are needed after the
source of the problem is discovered will likely be 2.6.34 and stable material.
Larry
---
Michael,
Please be aware that the failure in the SSB registration leads to a system
freeze when ssb is unloaded. I did a quick check but could not locate a
routine that fails to tear down all structures on an error return, but that
search will be easier once we know which routine is failing. The OP for the
Bugzilla entry has been given a test patch to further identify the problem.
Larry
---
Index: wireless-testing/drivers/ssb/main.c
===================================================================
--- wireless-testing.orig/drivers/ssb/main.c
+++ wireless-testing/drivers/ssb/main.c
@@ -834,6 +834,9 @@ int ssb_bus_pcibus_register(struct ssb_b
if (!err) {
ssb_printk(KERN_INFO PFX "Sonics Silicon Backplane found on "
"PCI device %s\n", dev_name(&host_pci->dev));
+ } else {
+ ssb_printk(KERN_ERR PFX "Failed to register PCI version"
+ " of SSB with error %d\n", err);
}
return err;
^ permalink raw reply
* pull request: wireless-next-2.6 2010-04-23
From: John W. Linville @ 2010-04-23 19:01 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Yet another huge batch of updates intended for 2.6.35. The ath9k driver
in particular gets a lot of attention, and the iwlwifi team continues
its usual strong showing.
Please let me know if there are problems! Again, this is for the
'for-davem' branch where I have pre-resolved some merge conflicts.
Thanks,
John
---
The following changes since commit c68ed255265968c3948fa2678bf59d15c471b055:
Tom Herbert (1):
bnx2x: add support for receive hashing
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Abhijeet Kolekar (1):
iwlwifi: add debugfs ops to iwlwifi
Benoit Papillault (1):
ath5k/ath9k: Fix 64 bits TSF reads
Christian Lamparter (1):
p54pci: fix serious sparse warning
Dan Williams (2):
libertas: consolidate SDIO firmware wait code
libertas: Davinci platforms need more time loading helper firmware
Daniel Halperin (1):
mac80211: fix typo in comments
Daniel Yingqiang Ma (1):
ath9k: Group Key fix for VAPs
David Kilroy (3):
orinoco: implement set_wiphy_params
orinoco: use cfg80211_find_ie
orinoco: have sparse check endian issues
Felix Fietkau (23):
ath9k_hw: add silicon revision macros for AR9300
ath9k_hw: add a macro for abstracting generic timer access
ath9k_hw: fix a missing hex prefix for a register mask
ath9k_hw: add simple register abstraction for some AR9300 registers
ath9k_hw: add support for GPIO differences on AR9003
ath9k_hw: Add AR9003 PHY register definitions
ath9k_hw: Set the channel on AR9003
ath9k_hw: Implement PLL control on AR9003
ath9k_hw: Implement spur mitigation on AR9003
ath9k_hw: Split off ANI control to the PHY ops
ath9k: Add Rx EDMA support
ath9k_hw: Split out the function for reading the noise floor
ath9k_hw: move AR9280 PCI EEPROM fix to eeprom_def.c
ath9k_hw: Update ath9k_hw_set_dma for AR9300
ath9k: check for specific rx stuck conditions and recover from them
ath9k: clean up tx buffer handling
ath9k: update the MCS mask for MCS16 and above
ath9k: update the ath_max_4ms_framelen table
ath9k: reduce the bits_per_symbol table size, support more streams
ath9k: initialize the number of tx/rx streams correctly
mac80211: add flags for STBC (Space-Time Block Coding)
ath9k: add support for Tx and Rx STBC
ath9k: set the STBC flag in rate control if the peer supports it
Grazvydas Ignotas (3):
wl1251: read default MAC address from EEPROM when available
wl1251: register platform_device to pass board data
wl1251: add support for dedicated IRQ line
Helmut Schaa (2):
rt2x00: add txdesc parameter to write_tx_data
rt2x00: rt2800pci: fix tx path by not accessing the skb after it was DMA mapped
Holger Schurig (2):
mac80211: sample survey implementation for mac80211 & hwsim
ath5k: basic support for survey
Johannes Berg (14):
iwlwifi: remove scan_bands logic
iwlwifi: correct atomic bitops usage
iwlwifi: remove next_scan_jiffies
iwlwifi: remove scan_pass_start
iwlwifi: rename priv->scan to priv->scan_cmd
iwlwifi: trigger scan synchronously
iwlwifi: make BT coex config a virtual method
iwlwifi: rename TX_CMD_FLG_BT_DIS_MSK
iwlwifi: don't check monitor for scanning
iwlwifi: remove monitor check
iwlwifi: make scan antenna forcing more generic
mac80211: fix stopping RX BA session from timer
mac80211: add missing newline
radiotap parser: fix endian annotation
John W. Linville (2):
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
Merge branch 'master' into for-davem
Juuso Oikarinen (2):
mac80211: Prevent running sta_cleanup timer unnecessarily
mac80211: Fix ieee80211_sta_conn_mon_timer with hw connection monitoring
Larry Finger (1):
rtl818x: Move configuration details to the rtl818x directory
Luis R. Rodriguez (54):
ath9k_hw: start building an abstraction layer for hardware routines
ath9k_hw: AR9003 does not have AR_RC_AHB skip its setting
ath9k_hw: remove wrapper ath9k_hw_write_regs()
ath9k_hw: Move some RF ops to the private callbacks
ath9k_hw: skip PLL initialization on AR9003 on Power-On-Reset
ath9k_hw: add some comments for ath9k_set_power_network_sleep()
ath9k_hw: add a private callback for PLL control computation
ath9k_hw: Add AR9003 PHY support
ath9k_hw: move init config and default after chip is up
ath9k_hw: add the AR9003 ar9003_hw_macversion_supported()
ath9k_hw: disable ANI for AR9003
ath9k: disable the MIB interrupt if ANI is disabled
ath9k_hw: add common channel select helpers for ar900[23]
ath9k_hw: split initvals.h by hardware family
ath9k_hw: add initvals for the AR9003 hardware family
ath9k_hw: add helpers for processing the AR9003 INI
ath9k_hw: add all the AR9003 PHY callbacks
ath9k_hw: add a helper for Power Amplifier calibration for AR9002
ath9k_hw: add a helper for the OLC tem compensation for AR9002
ath9k_hw: rename PA calib for AR9287
ath9k_hw: shift code for AR9280 OLC temp comp
ath9k_hw: move the AR9280 OLC temp comp to its own helper
ath9k_hw: simplify OLC temp compensation for AR9002
ath9k_hw: rename the PA calib routines to match their families
ath9k_hw: rename getNoiseFloorThresh() to ath9k_hw_loadnf()
ath9k_hw: move the cal AR9100 calibration settings
ath9k_hw: split calib code by hardware families
ath9k_hw: add the AR9003 ar9003_hw_init_cal callback
ath9k_hw: add the config_pci_powersave AR9003 callback
ath9k_hw: split the generic hardware code by hardware family
ath9k_hw: move the cck channel 14 INI to the AR9002 hw code
ath9k_hw: move TX/RX gain INI stuff to its own hardware family code
ath9k_hw: abstract the AR_PHY_AGC_CONTROL register access
ath9k_hw: abstract loading noisefloor
ath9k_hw: fill in the callbacks for calibration for AR9003
ath9k_hw: complete AR9003 calibration
ath9k_hw: rename eep_AR9287_ops to eep_ar9287_ops
ath9k_hw: restore mac address reading logic
ath9k_hw: add OFDM spur mitigation for AR9003
ath9k_hw: move the RF claim stuff to AR9002 hardware family
ath9k_hw: add the AR9300 SREV hw name print
ath9k_hw: add TX/RX gain register initialization for AR9003
ath9k_hw: skip asynch fifo enablement to AR9003
ath9k_hw: skip WEP aggregation enable code for AR9003
ath9k_hw: move AR9002 mac ops to its own file
ath9k: add RXLP and RXHP to debugfs counters
ath9k_hw: enable CRC check of descriptors for AR9003
ath9k_hw: set cwmin and cwmax to 0 for for AR9003 upon txq reset
mac80211: add LDPC control flag
ath9k_hw: add LDPC support for AR9003
ath9k: add LDPC support
ath9k_hw: add the PCI ID for the first AR9300 device
ath9k_hw: make two initvals consto for the AR9001 family
ath9k_hw: make all AR9002 initvals use u32
Nishant Sarmukadam (1):
cfg80211: Avoid sending IWEVASSOCREQIE and IWEVASSOCRESPIE events with NULL event body
Reinette Chatre (1):
Merge branch 'wireless-2.6' into wireless-next-2.6
Samuel Ortiz (2):
iwmc3200wifi: Fix sparse warnings
iwmc3200wifi: check sparse endianness annotations
Senthil Balasubramanian (5):
ath9k_hw: Add the PCI IDs for AR9300 and fill up the pci_id_tables
ath9k_hw: update the chip tests for AR9003
ath9k_hw: prevent reset control register zeroing on AR9003 reset
ath9k_hw: the eep_map is used only for AR9280 PCI card ini fixup
ath9k_hw: Implement AR9003 eeprom callbacks
Shanyu Zhao (2):
iwlwifi: bring up 6000 Series 2x2 AGN Gen2 adapters
iwlwifi: remove redundant iwl_dump_lq_cmd()
Stanislaw Gruszka (3):
iwlwifi: check scan request ie_len
iwlwifi: initialize iwl_wimax_coex_cmd.flags
mac80211: document IEEE80211_CONF_CHANGE_QOS
Sujith (10):
ath9k_htc: Cleanup beacon configuration
ath: Add buffered register write operations
ath9k_htc: Implement multiple register write support
ath9k_hw: Add macros for multiple register writes
ath9k_hw: Relocate Opmode initialization
ath9k_hw: Use buffered register writes
ath9k_htc: Remove GPIO set on unload
ath9k_htc: Add dropped SKB count to debugfs
ath9k_htc: Handle WMI timeouts properly
ath9k_htc: Fix sparse endian warnings
Vasanthakumar Thiagarajan (26):
ath9k_hw: Add hw cap flag for EDMA for the AR9003 family
ath9k_hw: Fill few hw cap for edma
ath9k_hw: Add abstraction for rx enable
ath9k_hw: Fill rx_enable() for the AR9003 hardware family
ath9k_hw: Add few routines for rx edma support
ath9k_hw: Define tx control struct for AR9003
ath9k_hw: Move code which populates ds_data to ath9k_hw
ath9k_hw: Add abstraction to set/get link pointer
ath9k: Use abstraction to get link pointer
ath9k: Use memcpy in ath_clone_txbuf()
ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose
ath9k: Make bf_desc of ath_buf opaque
ath9k_hw: Abstract the routine which returns interrupt status
ath9k_hw: Initialize interrupt mask for AR9003
ath9k_hw: Fill get_isr() for AR9003
ath9k_hw: Configure Tx interrupt mitigation timer
ath9k: Load SW filtered NF values and start NF cal during full reset for AR9003
ath9k_hw: Define abstraction for tx desc access
ath9k_hw: Add function to configure tx status ring buffer
ath9k_hw: Fill descriptor abstrations for AR9003
ath9k: Setup appropriate tx desc for regular dma and edma
ath9k: Initialize and configure tx status for EDMA
ath9k_hw: Compute pointer checksum over the link descriptor
ath9k: Add Tx EDMA support
ath9k: Enable TXOK and TXERR interrupts for TX EDMA
ath9k_hw: Abort rx if hw is not coming out of full sleep in reset
Wey-Yi Guy (7):
iwlwifi: set correct single/dual stream mask
iwlwifi: more generic eeprom defines
iwlwifi: remove duplicated debug functions
iwlwifi: add hw revision for 6000g2 NIC
iwlwifi: PA type for 6000g2 series
iwlwifi: sanity check for turn on aggregation tid
iwlwifi: more code clean up for agn devices
Xose Vazquez Perez (2):
wireless: rt2x00: rt2800usb: identify Hawking devices
wireless: rt2x00: rt2800usb: identify Allwin devices
drivers/net/wireless/Kconfig | 85 +-
drivers/net/wireless/ath/ath.h | 14 +-
drivers/net/wireless/ath/ath5k/base.c | 19 +
drivers/net/wireless/ath/ath5k/pcu.c | 31 +-
drivers/net/wireless/ath/ath9k/Makefile | 16 +-
drivers/net/wireless/ath/ath9k/ani.c | 208 +--
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 742 +++++++
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 1375 +++++++++++++
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 1254 ++++++++++++
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 1000 ++++++++++
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 593 ++++++
.../ath/ath9k/{initvals.h => ar9002_initvals.h} | 2052 +-------------------
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 480 +++++
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 539 +++++
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 572 ++++++
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 802 ++++++++
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 1856 ++++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 323 +++
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 205 ++
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 1793 +++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 611 ++++++
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 120 ++
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 1142 +++++++++++
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 847 ++++++++
drivers/net/wireless/ath/ath9k/ath9k.h | 24 +-
drivers/net/wireless/ath/ath9k/beacon.c | 5 +-
drivers/net/wireless/ath/ath9k/calib.c | 1089 +----------
drivers/net/wireless/ath/ath9k/calib.h | 19 +-
drivers/net/wireless/ath/ath9k/common.h | 4 +-
drivers/net/wireless/ath/ath9k/debug.c | 22 +-
drivers/net/wireless/ath/ath9k/debug.h | 4 +
drivers/net/wireless/ath/ath9k/eeprom.c | 9 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 22 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 17 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 9 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 13 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 13 +-
drivers/net/wireless/ath/ath9k/htc.h | 19 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 29 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 104 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 20 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 11 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 8 +-
drivers/net/wireless/ath/ath9k/htc_hst.h | 24 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 280 +++
drivers/net/wireless/ath/ath9k/hw.c | 1761 ++++-------------
drivers/net/wireless/ath/ath9k/hw.h | 253 +++-
drivers/net/wireless/ath/ath9k/init.c | 83 +-
drivers/net/wireless/ath/ath9k/mac.c | 490 ++---
drivers/net/wireless/ath/ath9k/mac.h | 67 +-
drivers/net/wireless/ath/ath9k/main.c | 82 +-
drivers/net/wireless/ath/ath9k/pci.c | 1 +
drivers/net/wireless/ath/ath9k/phy.c | 978 ----------
drivers/net/wireless/ath/ath9k/phy.h | 584 +------
drivers/net/wireless/ath/ath9k/rc.c | 13 +
drivers/net/wireless/ath/ath9k/recv.c | 518 ++++-
drivers/net/wireless/ath/ath9k/reg.h | 167 ++-
drivers/net/wireless/ath/ath9k/wmi.c | 16 +-
drivers/net/wireless/ath/ath9k/wmi.h | 19 +-
drivers/net/wireless/ath/ath9k/xmit.c | 488 ++++--
drivers/net/wireless/iwlwifi/Makefile | 1 +
drivers/net/wireless/iwlwifi/iwl-1000.c | 6 +
drivers/net/wireless/iwlwifi/iwl-3945.c | 2 +
drivers/net/wireless/iwlwifi/iwl-3945.h | 3 +
drivers/net/wireless/iwlwifi/iwl-4965.c | 15 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 11 +
drivers/net/wireless/iwlwifi/iwl-6000.c | 34 +-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 834 ++++++++
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.h | 56 +
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 2 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 403 ++++-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 47 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 42 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 36 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 50 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 3 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 46 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 18 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debug.h | 2 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 770 +-------
drivers/net/wireless/iwlwifi/iwl-dev.h | 9 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 32 +-
drivers/net/wireless/iwlwifi/iwl-prph.h | 80 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 506 +-----
drivers/net/wireless/iwlwifi/iwl-sta.c | 13 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 87 +-
drivers/net/wireless/iwmc3200wifi/Makefile | 2 +
drivers/net/wireless/iwmc3200wifi/rx.c | 3 +-
drivers/net/wireless/iwmc3200wifi/trace.h | 4 +-
drivers/net/wireless/iwmc3200wifi/tx.c | 4 +-
drivers/net/wireless/libertas/if_sdio.c | 103 +-
drivers/net/wireless/mac80211_hwsim.c | 28 +
drivers/net/wireless/orinoco/Makefile | 3 +
drivers/net/wireless/orinoco/cfg.c | 88 +-
drivers/net/wireless/orinoco/hw.c | 26 +
drivers/net/wireless/orinoco/main.h | 12 -
drivers/net/wireless/orinoco/orinoco.h | 2 +
drivers/net/wireless/orinoco/scan.c | 4 +-
drivers/net/wireless/orinoco/wext.c | 183 +--
drivers/net/wireless/p54/p54pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 34 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 26 +-
drivers/net/wireless/rt2x00/rt2x00.h | 3 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00pci.h | 3 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 3 +-
drivers/net/wireless/rtl818x/Kconfig | 88 +
drivers/net/wireless/wl12xx/wl1251_main.c | 63 +
drivers/net/wireless/wl12xx/wl1251_reg.h | 7 +
drivers/net/wireless/wl12xx/wl1251_sdio.c | 96 +-
include/linux/ieee80211.h | 1 +
include/linux/spi/wl12xx.h | 2 +
include/net/cfg80211.h | 2 +-
include/net/mac80211.h | 17 +-
net/mac80211/agg-rx.c | 18 +-
net/mac80211/agg-tx.c | 2 +-
net/mac80211/cfg.c | 12 +
net/mac80211/driver-ops.h | 9 +
net/mac80211/key.c | 1 +
net/mac80211/mlme.c | 5 +
net/mac80211/sta_info.c | 13 +-
net/mac80211/tx.c | 7 +
net/wireless/sme.c | 16 +-
127 files changed, 19021 insertions(+), 8935 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/ar5008_initvals.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar5008_phy.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9001_initvals.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9002_calib.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9002_hw.c
rename drivers/net/wireless/ath/ath9k/{initvals.h => ar9002_initvals.h} (78%)
create mode 100644 drivers/net/wireless/ath/ath9k/ar9002_mac.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9002_phy.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9002_phy.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_calib.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_hw.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_initvals.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_mac.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_mac.h
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_phy.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_phy.h
create mode 100644 drivers/net/wireless/ath/ath9k/hw-ops.h
delete mode 100644 drivers/net/wireless/ath/ath9k/phy.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-agn-debugfs.h
create mode 100644 drivers/net/wireless/rtl818x/Kconfig
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-04-23.patch.bz2
--
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: RTL 8187b - naughty behaviour
From: Gábor Stefanik @ 2010-04-23 20:16 UTC (permalink / raw)
To: Rogerio Luz Coelho
Cc: Larry Finger, linux-wireless, Herton Ronaldo Krzesinski
In-Reply-To: <u2k917a57cb1004221345i19eb6354yffdc302f6a9b74c6@mail.gmail.com>
2010/4/22 Rogerio Luz Coelho <rogluz.news@gmail.com>:
> 2010/4/11 Gábor Stefanik <netrolller.3d@gmail.com>:
>> 2010/4/10 Rogerio Luz Coelho <rogluz.news@gmail.com>:
>>> 2010/4/10 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>> On Sat, Apr 10, 2010 at 2:07 PM, Rogerio Luz Coelho
>>>> <rogluz.news@gmail.com> wrote:
>>>>> 2010/4/3 Rogerio Luz Coelho <rogluz.news@gmail.com>:
>>>>>> 2010/4/3 Larry Finger <Larry.Finger@lwfinger.net>:
>>>>>>> On 04/03/2010 11:49 AM, Rogerio Luz Coelho wrote:
>>>>>>>>
>>>>>>>> I have a MS-Win7 instalation on this Laptop and it works 100% even at
>>>>>>>> longer distances than you report,even with walls in between.
>>>>>>>>
>>>>>>>> Will do the tcpperf test as soon as I get home. There are other with
>>>>>>>> the same problem with my exact chip here in Brasil , that is because
>>>>>>>> one of our leading Laptop vendors uses this config.
>>>>>>>
>>>>>>> What is the exact make and model of the device? It might be difficult
>>>>>>> for me to get one in the US, but one of the rtl8187 developers lives in
>>>>>>> Brazil. He should be able to find one.
>>>>>>>
>>>>>>
>>>>>> It愀 a POSITIVO R430L - Core 2 Duo 4GB RAM
>>>>>>
>>>>>>
>>>>>>>> Does it matter that the USB port used in this setting is a connected
>>>>>>>> to a USB HUB and then to the mother board?
>>>>>>>
>>>>>>> Is the hub passive, or is it powered? If the hub is good and not
>>>>>>> underpowered, it should be OK.
>>>>>>>
>>>>>>>> More details and tests will come your way in a day or two ... will
>>>>>>>> reinstall Mandriva 2010 and do some tests with older kernels.
>>>>>>>
>>>>>>> If you can download an openSUSE 11.2 Live CD and burn it, you would not
>>>>>>> even have to do an installation. That one has a 2.6.31 kernel.
>>>>>>>
>>>>>>> Larry
>>>>>
>>>>>
>>>>> Downloaded and installed:
>>>>>
>>>>> OpenSuse 11.2 - LiveCD result: Gnome Network-Manager tells me there
>>>>> is connection but no ping resposes, Firefox complains about conections
>>>>> errors.
>>>>>
>>>>> Mandriva 2010.0 (kernel 2.6.31-12) result: concection comes and goes
>>>>> ... generally the first boot of the day connects, but it lasts less
>>>>> than 5min. The error code is the "deauthentication by local reason
>>>>> (reason=3) again.
>>>>>
>>>>> MS-Win7 : connects and is as fast as ever.
>>>>>
>>>>> -- Any other suggestions?
>>>>>
>>>>> Rogerio
>>>>>
>>>>> PS: Will give OpenSuse a HD install atempt and will try to debug the
>>>>> Mandriva for some time, future tries involve Debian Stable (old
>>>>> kernel) and some Fedora (any suggestions?) and the NDISwrapper drive
>>>>> in a Debian Testing (the Distro I need working)
>>>>
>>>> Hi,
>>>>
>>>> Please also test Realtek's official r8187b driver. If possible, please
>>>> do an mmiotrace on that driver.
>>>
>>> Ok ... The official Realtek is only for 32bits systems right ? ( At
>>> least the guys at Realtek support told me so... ) and this mmiotrace
>>> can be accomplished how? Is it a program, a command, a debug message
>>> in some form? Sorry, as I said earlier I am NOT a kernel programer.
>>>
>>> Rogerio
>>>
>>
>> You need to enable MMIO tracing support in your kernel config, and
>> recompile your kernel (assuming it is not enabled already - distros
>> usually disable the entire tracing framework by default). Then:
>> -Mount debugfs to /debug. (Usually it is mounted by default, but some
>> distros like to mount it @ /sys/kernel/debug instead - remount it to
>> /debug.)
>> -"echo mmiotrace > /debug/tracing/current_tracer"
>> -"cat /debug/tracing/trace_pipe > trace.txt &" - at this point, tracing begins.
>> -Load r8187b and connect.
>> -"echo "Driver loaded!" > /debug/tracing/trace_marker"
>> -"echo nop > /debug/tracing/current_tracer" - tracing ends here.
>>
>> Do this for rtl8187 as well.
>> After each trace, check if "grep -i lost trace.txt" returns anything.
>> If it does, enlarge the trace buffer and retry:
>> -"cat /debug/tracing/trace_buffer_kb"
>> -"echo [BUFSIZE] > /debug/tracing/trace_buffer_kb", where [BUFSIZE] is
>> recommended to be about twice the number returned by the previous
>> command.
>
> I installed a vanilla kernel 2.6.32.11 , config to rum mmio , but my
> rtl818x modules are loaded by default and the modprobe -r command
> doesn't seem to change this ... any ideas ?
>
> Rogerio
Did you build rtl8187 as a module? Otherwise modprobe -r can do nothing.
>
>
>>
>> Repeat these steps until the "lost events" warning disappears. Once
>> you find the right BUFSIZE for one driver, you can use the same size
>> for the other one too.
>>
>> Hth,
>> Gábor
>>
>> --
>> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 07/11] ath9k_htc: Use USB reboot
From: Gábor Stefanik @ 2010-04-23 20:18 UTC (permalink / raw)
To: Sujith; +Cc: linville, linux-wireless
In-Reply-To: <19409.10472.450708.915467@gargle.gargle.HOWL>
On Fri, Apr 23, 2010 at 6:58 AM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> So, apparently there is a USB reboot command
> that the target accepts. Using this instead of
> usb_reset_device() fixes the issue of "descriptor read error"
> that pops up on repeated load/unload.
>
> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index cee5feb..31665c5 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -889,6 +889,26 @@ err_alloc:
> return ret;
> }
>
> +static void ath9k_hif_usb_reboot(struct usb_device *udev)
> +{
> + u32 reboot_cmd = 0xffffffff;
> + void *buf;
> + int ret;
> +
> + buf = kmalloc(4, GFP_KERNEL);
> + if (!buf)
> + return;
> +
> + memcpy(buf, &reboot_cmd, 4);
> +
> + ret = usb_bulk_msg(udev, usb_sndbulkpipe(udev, USB_REG_OUT_PIPE),
> + buf, 4, NULL, HZ);
> + if (ret)
> + dev_err(&udev->dev, "ath9k_htc: USB reboot failed\n");
> +
> + kfree(buf);
> +}
> +
> static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
> {
> struct usb_device *udev = interface_to_usbdev(interface);
> @@ -903,7 +923,7 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
> }
>
> if (hif_dev->flags & HIF_USB_START)
> - usb_reset_device(udev);
> + ath9k_hif_usb_reboot(udev);
>
> kfree(hif_dev);
> dev_info(&udev->dev, "ath9k_htc: USB layer deinitialized\n");
> --
> 1.7.0.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
This patch seems to be the wrong way around... or is it supposed to be
applied using "patch -R"?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-04-23
From: David Miller @ 2010-04-23 23:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100423190139.GA7276@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 23 Apr 2010 15:01:40 -0400
> Yet another huge batch of updates intended for 2.6.35. The ath9k driver
> in particular gets a lot of attention, and the iwlwifi team continues
> its usual strong showing.
>
> Please let me know if there are problems! Again, this is for the
> 'for-davem' branch where I have pre-resolved some merge conflicts.
Pulled, thanks John.
^ permalink raw reply
* [178/197] mac80211: fix deferred hardware scan requests
From: Chase Douglas @ 2010-04-23 23:50 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20100422190923.333971365@kvm.kroah.org>
As Luis Rodriguez pointed out, I should have cc'd linux-wireless on
this from the beginning. I hope no one has any objections to this
going out as part of the next stable drop.
Thanks
-- Chase
---------- Forwarded message ----------
From: Greg KH <gregkh@suse.de>
Date: Thu, Apr 22, 2010 at 3:10 PM
Subject: [178/197] mac80211: fix deferred hardware scan requests
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Johannes Berg
<johannes@sipsolutions.net>, "John W. Linville"
<linville@tuxdriver.com>, Chase Douglas <chase.douglas@canonical.com>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Johannes Berg <johannes@sipsolutions.net>
commit c0ce77b8323c1a0d4eeef97caf16c0ea971222a9 upstream.
Reinette found the reason for the warnings that
happened occasionally when a hw-offloaded scan
finished; her description of the problem:
mac80211 will defer the handling of scan requests if it is
busy with management work at the time. The scan requests
are deferred and run after the work has completed. When
this occurs there are currently two problems.
* The scan request for hardware scan is not fully populated
with the band and channels to scan not initialized.
* When the scan is queued the state is not correctly updated
to reflect that a scan is in progress. The problem here is
that when the driver completes the scan and calls
ieee80211_scan_completed() a warning will be triggered
since mac80211 was not aware that a scan was in progress.
The reason is that the queued scan work will start
the hw scan right away when the hw_scan_req struct
has already been allocated. However, in the first
pass it will not have been filled, which happens
at the same time as setting the bits. To fix this,
simply move the allocation after the pending work
test as well, so that the first iteration of the
scan work will call __ieee80211_start_scan() even
in the hardware scan case.
Bug-identified-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/mac80211/scan.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -408,6 +408,16 @@ static int __ieee80211_start_scan(struct
if (local->scan_req)
return -EBUSY;
+ if (req != local->int_scan_req &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !list_empty(&ifmgd->work_list)) {
+ /* actually wait for the work it's doing to finish/time out */
+ set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
+ local->scan_req = req;
+ local->scan_sdata = sdata;
+ return 0;
+ }
+
if (local->ops->hw_scan) {
u8 *ies;
int ielen;
@@ -428,14 +438,6 @@ static int __ieee80211_start_scan(struct
local->scan_req = req;
local->scan_sdata = sdata;
- if (req != local->int_scan_req &&
- sdata->vif.type == NL80211_IFTYPE_STATION &&
- !list_empty(&ifmgd->work_list)) {
- /* actually wait for the work it's doing to finish/time out */
- set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
- return 0;
- }
-
if (local->ops->hw_scan)
__set_bit(SCAN_HW_SCANNING, &local->scanning);
else
^ permalink raw reply
* Re: [PATCH 07/11] ath9k_htc: Use USB reboot
From: Sujith @ 2010-04-24 0:47 UTC (permalink / raw)
To: G bor Stefanik; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <s2m69e28c911004231318oaf7cd7fex440846d2f90a5774@mail.gmail.com>
G bor Stefanik wrote:
> This patch seems to be the wrong way around... or is it supposed to be
> applied using "patch -R"?
What's wrong ?
Sujith
^ permalink raw reply
* Re: [PATCH 07/11] ath9k_htc: Use USB reboot
From: Gábor Stefanik @ 2010-04-24 1:38 UTC (permalink / raw)
To: Sujith; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <19410.16272.850309.781236@gargle.gargle.HOWL>
2010/4/24 Sujith <Sujith.Manoharan@atheros.com>:
> G bor Stefanik wrote:
>> This patch seems to be the wrong way around... or is it supposed to be
>> applied using "patch -R"?
>
> What's wrong ?
>
> Sujith
>
Sorry... I apparently thought you were trying to *remove* USB reboot
support, rather than add it.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Felix Fietkau @ 2010-04-24 3:45 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linville, linux-wireless, stable, Ranga Rao Ravuri
In-Reply-To: <1272007564-6265-1-git-send-email-vnatarajan@atheros.com>
On 2010-04-23 9:26 AM, Vivek Natarajan wrote:
> If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
> with WEP or TKIP, eventhough the received frame may be a CRC failed
> corrupted frame.
>
> Cc: stable@kernel.org
> Reported-by: Johan Hovold <johan.hovold@lundinova.se>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
> Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 2 +-
> drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
> index cd953f6..025c31a 100644
> --- a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
> +++ b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
> @@ -249,7 +249,7 @@ static const u32 ar5416Common[][2] = {
> { 0x00008258, 0x00000000 },
> { 0x0000825c, 0x400000ff },
> { 0x00008260, 0x00080922 },
> - { 0x00008264, 0xa8000010 },
> + { 0x00008264, 0x88000010 },
I don't think this is enough. This register is called
AR_MAC_PCU_LOGIC_ANALYZER and the field you're modifying
(AR_MAC_PCU_LOGIC_ANALYZER_DISBUG20768) is being touched by the function
ar9002_hw_enable_async_fifo() in ar9002_hw.c.
So unless this AR9287 v1.2 or later is unaffected by this issue, the
REG_SET_BIT call should be removed as well.
By the way, is this change in the other Atheros codebases as well? If
so, maybe this change should go into the ini override functions instead,
to make it easier to keep initvals in sync.
- Felix
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox