- 09 Apr, 2010 1 commit
-
-
Johannes Berg authored
The current algorithm will sometimes "detect" that more chains are enabled than are really present in the device because, for unknown reasons, the ucode sends up all-zeroes signal values. The simplest way of solving this is to restrict the active chains mask to the chains we know are really present on the device. This fixes a bug with some devices where, since sometimes more chains are enabled than really present, the system would hang. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
-
- 08 Apr, 2010 1 commit
-
-
Wey-Yi Guy authored
For 4965, need to check it is valid qos frame before free, only valid QoS frame has the tid used to free the packets. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 06 Apr, 2010 3 commits
-
-
Felix Fietkau authored
With the enable_radio being uninitialized, ath_radio_enable() might be called twice, which can leave some hardware in an undefined state. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The new RCU lockdep support warns about these in some contexts -- make it aware of the locks used to protect all this. Different locks are used in different contexts which unfortunately means we can't get perfect checking. Also remove rcu_dereference() from two places that don't actually dereference the pointers. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
This fixes the problem introduced in commit 84040805 which broke mesh peer link establishment. changes: v2 Added missing break (Johannes) v3 Broke original patch into two (Johannes) Signed-off-by: Javier Cardona <javier@cozybit.com> Cc: stable@kernel.org Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 02 Apr, 2010 3 commits
-
-
Zhu Yi authored
We used to free all the Tx queues memory when interface is brought down and reallocate them again in interface up. This requires order-4 allocation for txq->cmd[]. In situations like s2ram, this usually leads to allocation failure in the memory subsystem. The patch fixed this problem by allocating the Tx queues memory only at the first time. Later iwl_down/iwl_up only initialize but don't free and reallocate them. The memory is freed at the device removal time. BTW, we have already done this for the Rx queue. This fixed bug https://bugzilla.kernel.org/show_bug.cgi?id=15551Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
-
Shanyu Zhao authored
When collecting tx data for non-aggregation packets in rate scaling, if the tx data matches "other table", it still uses current table to update the stats and calculate average throughput in function rs_collect_tx_data(). This can mess up the rate scaling data structure and cause a kernel panic in a BUG_ON statement in rs_rate_scale_perform(). To fix this bug, we pass table pointer instead of window pointer (pointed to by table pointer) to function rs_collect_tx_data() so that the table being used is consistent. Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: Henry Zhang <hongx.c.zhang@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
-
Zhu Yi authored
Below warning is triggered sometimes at module removal time when CONFIG_DMA_API_DEBUG is enabled. This should be caused by we didn't unmap pending commands (enqueued, but no complete notification received) for the Tx command queue. [ 1583.107469] ------------[ cut here ]------------ [ 1583.107539] WARNING: at lib/dma-debug.c:688 dma_debug_device_change+0x13c/0x180() [ 1583.107617] Hardware name: ... [ 1583.107664] pci 0000:04:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=1] [ 1583.107713] Modules linked in: ... [ 1583.111661] Pid: 16970, comm: modprobe Tainted: G W 2.6.34-rc1-wl #33 [ 1583.111727] Call Trace: [ 1583.111779] [<c02a281c>] ? dma_debug_device_change+0x13c/0x180 [ 1583.111833] [<c02a281c>] ? dma_debug_device_change+0x13c/0x180 [ 1583.111908] [<c0138e11>] warn_slowpath_common+0x71/0xd0 [ 1583.111963] [<c02a281c>] ? dma_debug_device_change+0x13c/0x180 [ 1583.112016] [<c0138ebb>] warn_slowpath_fmt+0x2b/0x30 [ 1583.112086] [<c02a281c>] dma_debug_device_change+0x13c/0x180 [ 1583.112142] [<c03e6c33>] notifier_call_chain+0x53/0x90 [ 1583.112198] [<c03e1ebe>] ? down_read+0x6e/0x90 [ 1583.112271] [<c015b229>] __blocking_notifier_call_chain+0x49/0x70 [ 1583.112326] [<c015b26f>] blocking_notifier_call_chain+0x1f/0x30 [ 1583.112380] [<c031931c>] __device_release_driver+0x8c/0xa0 [ 1583.112451] [<c03193bf>] driver_detach+0x8f/0xa0 [ 1583.112538] [<c0318382>] bus_remove_driver+0x82/0x100 [ 1583.112595] [<c0319ad9>] driver_unregister+0x49/0x80 [ 1583.112671] [<c024feb2>] ? sysfs_remove_file+0x12/0x20 [ 1583.112727] [<c02aa292>] pci_unregister_driver+0x32/0x80 [ 1583.112791] [<fc13a3c1>] iwl_exit+0x12/0x19 [iwlagn] [ 1583.112848] [<c017940a>] sys_delete_module+0x15a/0x210 [ 1583.112870] [<c015a5db>] ? up_read+0x1b/0x30 [ 1583.112893] [<c029600c>] ? trace_hardirqs_off_thunk+0xc/0x10 [ 1583.112924] [<c0295ffc>] ? trace_hardirqs_on_thunk+0xc/0x10 [ 1583.112947] [<c03e6a1f>] ? do_page_fault+0x1ff/0x3c0 [ 1583.112978] [<c03e36f6>] ? restore_all_notrace+0x0/0x18 [ 1583.113002] [<c016aa70>] ? trace_hardirqs_on_caller+0x20/0x190 [ 1583.113025] [<c0102d58>] sysenter_do_call+0x12/0x38 [ 1583.113054] ---[ end trace fc23e059cc4c2ced ]--- Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
-
- 30 Mar, 2010 15 commits
-
-
Daniel Mack authored
The libertas driver calls wiphy_unregister() without a prior wiphy_register() when a devices fails initialization. Fix this by introducing a private flag. [ 9.310000] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [...] [ 9.330000] [<c0311310>] (wiphy_unregister+0xfc/0x19c) from [<bf00c9ec>] (lbs_cfg_free+0x70/0x9c [libertas]) [ 9.330000] [<bf00c9ec>] (lbs_cfg_free+0x70/0x9c [libertas]) from [<bf014fdc>] (lbs_remove_card+0x180/0x210 [libertas]) [ 9.330000] [<bf014fdc>] (lbs_remove_card+0x180/0x210 [libertas]) from [<bf035394>] (if_sdio_probe+0xdc4/0xef4 [libertas_sdio]) [ 9.330000] [<bf035394>] (if_sdio_probe+0xdc4/0xef4 [libertas_sdio]) from [<c0230d14>] (sdio_bus_probe+0xd4/0xf0) [ 9.330000] [<c0230d14>] (sdio_bus_probe+0xd4/0xf0) from [<c01a6034>] (driver_probe_device+0xa4/0x174) [ 9.330000] [<c01a6034>] (driver_probe_device+0xa4/0x174) from [<c01a6164>] (__driver_attach+0x60/0x84) [ 9.330000] [<c01a6164>] (__driver_attach+0x60/0x84) from [<c01a5854>] (bus_for_each_dev+0x4c/0x8c) [ 9.330000] [<c01a5854>] (bus_for_each_dev+0x4c/0x8c) from [<c01a50e4>] (bus_add_driver+0xa0/0x228) [ 9.330000] [<c01a50e4>] (bus_add_driver+0xa0/0x228) from [<c01a6470>] (driver_register+0xc0/0x150) [ 9.330000] [<c01a6470>] (driver_register+0xc0/0x150) from [<bf03a06c>] (if_sdio_init_module+0x6c/0x108 [libertas_sdio]) [ 9.330000] [<bf03a06c>] (if_sdio_init_module+0x6c/0x108 [libertas_sdio]) from [<c00263ac>] (do_one_initcall+0x5c/0x1bc) [ 9.330000] [<c00263ac>] (do_one_initcall+0x5c/0x1bc) from [<c0069f80>] (sys_init_module+0xc0/0x1f0) [ 9.330000] [<c0069f80>] (sys_init_module+0xc0/0x1f0) from [<c0026f00>] (ret_fast_syscall+0x0/0x30) Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: Dan Williams <dcbw@redhat.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Holger Schurig <hs4233@mail.mn-solutions.de> Cc: Bing Zhao <bzhao@marvell.com> Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
IWL_RATE_COUNT is 13 and IWL_RATE_COUNT_LEGACY is 12. IWL_RATE_COUNT_LEGACY is the right one here because iwl3945_rates doesn't support 60M and also that's how "rates" is defined in iwlcore_init_geos() from drivers/net/wireless/iwlwifi/iwl-core.c. rates = kzalloc((sizeof(struct ieee80211_rate) * IWL_RATE_COUNT_LEGACY), GFP_KERNEL); Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: stable@kernel.org Acked-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Valentin Longchamp authored
An int urb is constructed but we fill it in with a bulk pipe type. Commit f661c6f8 implemented a pipe type check when CONFIG_USB_DEBUG is enabled. The check failed for all the ar9170 usb transfers and the driver could not configure the wifi dongle. This went unnoticed until now because most people don't have CONFIG_USB_DEBUG enabled. Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch> Cc: Stable <stable@kernel.org> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
Recent bug reports have shown that rt2500usb also suffers from the powersave problems that the PCI rt2x00 drivers suffer from. So disable powersaving by default for rt2500usb as well. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Shanyu Zhao authored
Previously in interrupt handling tasklet, iwlwifi driver only clear/ack those interrupts that are enabled by the driver through inta_mask. If the hardware generates unattended interrupts, driver will not ack them, defeating the interrupt coalescing feature. This results in high number of interrupts per second and high CPU utilization. This patch addresses this issue by acking those unattended interrupts in the tasklet. Local test showed an order of magnitude improvement in terms of the number of interrupts without sacrificing networking throughput. This is a workaround for hardware issue. Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
-
Wey-Yi Guy authored
Forget one hunk in 4965 during "iwlwifi: error checking for number of tfds in queue" patch. Reported-by: Shanyu Zhao <shanyu.zhao@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org
-
Reinette Chatre authored
Commit "cfg80211: convert bools into flags" mistakenly modified iwlwifi's regulatory settings instead of just converting it. Fix this. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2172Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> CC: stable@kernel.org
-
Johannes Berg authored
"mac80211: fix skb buffering issue" still left a race between enabling the hardware queues and the virtual interface queues. In hindsight it's totally obvious that enabling the netdev queues for a hardware queue when the hardware queue is enabled is wrong, because it could well possible that we can fill the hw queue with packets we already have pending. Thus, we must only enable the netdev queues once all the pending packets have been processed and sent off to the device. In testing, I haven't been able to trigger this race condition, but it's clearly there, possibly only when aggregation is being enabled. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hans de Goede authored
Thanks to Chris Chabot for giving his old wireless usb dongle to me to test it under Linux. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Benjamin Larsson authored
Signed-off-by: Benjamin Larsson <banan@ludd.ltu.se> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Konrath authored
This patch adds support for the NEC WL300NU-G USB wifi dongle. Signed-off-by: Ben Konrath <ben@bagu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Porsch, Marco authored
1st) a PREQ should only be processed, if it has the same SN and better metric (instead of better or equal). 2nd) next_hop[ETH_ALEN] now actually used to buffer mpath->next_hop->sta.addr for use out of lock. Signed-off-by: Marco Porsch <marco.porsch@siemens.com> Acked-by: Javier Cardona <javier@cozybit.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Stanse discovered that kmalloc is being called with GFP_KERNEL while holding this spinlock. The spinlock can be a mutex instead, which also enables the removal of the unlock/lock around the lock/unlock of cfg80211_mutex and the call to set_regdom. Reported-by: Jiri Slaby <jirislaby@gmail.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 16 Mar, 2010 3 commits
-
-
Adel Gadllah authored
Commit a239a8b4 introduced a noisy message, that fills up the log very fast. The error seems not to be fatal (the connection is stable and performance is ok), so make it IWL_DEBUG_TX rather than IWL_ERR. Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com> Cc: stable@kernel.org Acked-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When I initially stumbled upon sequence number problems with PAE frames in ath9k, I submitted a patch to remove all special cases for PAE frames and let them go through the normal transmit path. Out of concern about crypto incompatibility issues, this change was merged instead: commit 6c8afef5 Author: Sujith <Sujith.Manoharan@atheros.com> Date: Tue Feb 9 10:07:00 2010 +0530 ath9k: Fix sequence numbers for PAE frames After a lot of testing, I'm able to reliably trigger a driver crash on rekeying with current versions with this change in place. It seems that the driver does not support sending out regular MPDUs with the same TID while an A-MPDU session is active. This leads to duplicate entries in the TID Tx buffer, which hits the following BUG_ON in ath_tx_addto_baw(): index = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno); cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1); BUG_ON(tid->tx_buf[cindex] != NULL); I believe until we actually have a reproducible case of an incompatibility with another AP using no PAE special cases, we should simply get rid of this mess. This patch completely fixes my crash issues in STA mode and makes it stay connected without throughput drops or connectivity issues even when the AP is configured to a very short group rekey interval. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grazvydas Ignotas authored
In case debugfs does not init for some reason (or is disabled on older kernels) driver does not allocate stats.fw_stats structure, but tries to clear it later and trips on a NULL pointer: Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at __memzero+0x24/0x80 Backtrace: [<bf0ddb88>] (wl1251_debugfs_reset+0x0/0x30 [wl1251]) [<bf0d6a2c>] (wl1251_op_stop+0x0/0x12c [wl1251]) [<bf0bc228>] (ieee80211_stop_device+0x0/0x74 [mac80211]) [<bf0b0d10>] (ieee80211_stop+0x0/0x4ac [mac80211]) [<c02deeac>] (dev_close+0x0/0xb4) [<c02deac0>] (dev_change_flags+0x0/0x184) [<c031f478>] (devinet_ioctl+0x0/0x704) [<c0320720>] (inet_ioctl+0x0/0x100) Add a NULL pointer check to fix this. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Acked-by: Kalle Valo <kalle.valo@iki.fi> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 10 Mar, 2010 13 commits
-
-
Eric Dumazet authored
Fix memory leak and use kmalloc() instead of kzalloc() as we are going to overwrite the allocated buffer. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Juuso Oikarinen authored
Currently hardware with !IEEE80211_HW_PS_NULLFUNC_STACK and IEEE80211_HW_REPORTS_TX_ACK_STATUS will never enter PSM due to the conditions in the power save entry functions. Fix those conditions. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
Fixed below compiler warning: drivers/net/wireless/ipw2x00/ipw2200.c: In function ‘ipw_load_firmware’: drivers/net/wireless/ipw2x00/ipw2200.c:3260: warning: the frame size of 1168 bytes is larger than 1024 bytes Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
we read the IQ correction values (i_cal and q_cal) for G mode from a wrong location (the same shifts as for A mode is applied which is incorrect). use correct locations, matching the docs and HAL sources. also we should write IQ correction only when we have that information in the EEPROM, starting from version 4. also write it in the same way as we do in the periodic recalibration (enable last), just to be sure. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
I/Q calibration was completely broken, resulting in a high number of CRC errors on received packets. before i could see around 10% to 20% CRC errors, with this patch they are between 0% and 3%. 1.) the removal of the mask in commit "ath5k: Fix I/Q calibration (f1cf2dbd)" resulted in no mask beeing used when writing the I/Q values into the register. additional errors in the calculation of the values (see 2.) resulted too high numbers, exceeding the masks, so wrong values like 0xfffffffe were written. to be safe we should always use the bitmask when writing parts of a register. 2.) using a (s32) cast for q_coff is a wrong conversion to signed, since we convert to a signed value later by substracting 128. this resulted in too low numbers for Q many times, which were limited to -16 by the boundary check later on. 3.) checked everything against the HAL sources and took over comments and minor optimizations from there. 4.) we can't use ENABLE_BITS when we want to write a number (the number can contain zeros). also always write the correction values first and set ENABLE bit last, like the HAL does. Signed-off-by: Bruno Randolf <br1@einfach.org> Cc: stable@kernel.org Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
to reset the TSF, AR5K_BEACON_RESET_TSF has to be 1, not 0. also we have a function for that so use it. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
when using a fixed antenna we should use the antenna number in all tx descriptors, otherwise the hardware will sometimes send the frame out on the other antenna. it seems like the hardware does not always respect the default antenna and diversity settings (esp. AR5K_STA_ID1_DEFAULT_ANTENNA). also i would like to note that antenna diversity does not always work correctly on 5414 (at least) when only one antenna is connected: for example all frames might be received on antenna A but still the HW tries to send on antenna B some times, causing packet loss. this is both verified with the antenna statistics output of the previous patch and a spectrum analyzer. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
The ieee->networks consists of 128 struct libipw_network entries. If we allocate this chunk of memory altogether, it ends up with an order 4 page allocation. High order page allocation is likely to fail on system high load. This patch splits the big chunk memory allocation into small pieces, each is 344 bytes, allocates them with 128 times. The patch fixed bug http://bugzilla.kernel.org/show_bug.cgi?id=14989Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jouni Malinen authored
Commit 34e89507 introduced sta_mtx locking into sta_info_insert() (now sta_info_insert_rcu), but forgot to unlock this mutex on one of the error paths. Fix this by adding the missing mutex_unlock() call for the case where STA insert fails due to an entry existing already. This may happen at least in AP mode when a STA roams between two BSSes (vifs). Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Remove the KSEG1ADDR define from rt2x00soc.h as it redefines and covers the correct one from the arch/mips/include/asm/addrspace.h. Otherwise the driver oopses on the target platform (Ralink rt3050 board). Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Reinette Chatre authored
This reverts commit 21b2d8bd. As explained by Johannes: When we build a probe request frame in the buffer with the SSID, we could arrive over the limit of 200 bytes. When we build it in the buffer without the SSID (wildcard) we don't arrive over 200 bytes, but the ucode still allows direct probe in addition because it has an internal buffer that is larger when it inserts the SSID... Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
-
Reinette Chatre authored
Recent patch "iwlwifi: move 3945 clip groups to 3945 data" exposed a memory corruption problem. When initializing the clip groups the code was mistakenly using the iwlagn rate count, not the 3945 rate count. This resulted in more memory being written than was allocated. "iwlwifi: move 3945 clip groups to 3945 data" moved the location where the clip groups are stored and the impact is now severe in that the number of configured TX queues is modified. Previously the "temperature" field was overwritten, which did not seem to affect the operation. Fix this one instance where wrong rate count was used. I also noticed one more location where the iwlagn rate count was used to index an iwl3945 array, fix this. I also modified one location that modified the iwlagn rate count to obtain the iwl3945 rate count ... just use the iwl3945 rate count directly. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2165 and http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2168Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
- 08 Mar, 2010 1 commit
-
-
Wolfgang Grandegger authored
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-