- 02 3月, 2011 2 次提交
-
-
由 Felix Fietkau 提交于
Also fix a typo in the STATION_INFO_TX_BITRATE description Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The AID and BSSID should be set in the HW only for the first station interface or adhoc interface. Also, cancel the ANI timer in stop() for multi-STA scenario. And finally configure the HW beacon timers only for the first station interface. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 3月, 2011 14 次提交
-
-
由 Stanislaw Gruszka 提交于
There is no need to have separate iwl-agn-rx.c file after iwlegacy split. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Remove check_plcp_health and check_ack_health ops methods, they are unneeded after iwlegacy driver split. Merge check health code into to iwl-rx.c and make functions static. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Add module ack_check, and plcp_check parameters. Ack_check is disabled by default since is proved that check ack health can cause troubles. Plcp_check is enabled by default. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Fix possible dma mappings and skbs introduced by commit 470058e0 "iwlwifi: avoid Tx queue memory allocation in interface down". Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Since commit commit 470058e0 "iwlwifi: avoid Tx queue memory allocation in interface down" we do not unmap dma and free skbs when down device and there is pending transfer. What in consequence may cause that system hung (waiting for free skb's) when performing shutdown at iptables module unload. DMA leak manifest itself following warning: WARNING: at lib/dma-debug.c:689 dma_debug_device_change+0x15a/0x1b0() Hardware name: HP xw8600 Workstation pci 0000:80:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=240] Modules linked in: iwlagn(-) aes_x86_64 aes_generic fuse cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod uinput hp_wmi sparse_keymap sg wmi microcode serio_raw tg3 arc4 ecb shpchp mac80211 cfg80211 rfkill ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif firewire_ohci firewire_core crc_itu_t mptsas mptscsih mptbase scsi_transport_sas pata_acpi ata_generic ata_piix ahci libahci floppy nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iwlagn] Pid: 9131, comm: rmmod Tainted: G W 2.6.38-rc6-wl+ #33 Call Trace: [<ffffffff810649ef>] ? warn_slowpath_common+0x7f/0xc0 [<ffffffff81064ae6>] ? warn_slowpath_fmt+0x46/0x50 [<ffffffff812320ab>] ? dma_debug_device_change+0xdb/0x1b0 [<ffffffff8123212a>] ? dma_debug_device_change+0x15a/0x1b0 [<ffffffff8149dc18>] ? notifier_call_chain+0x58/0xb0 [<ffffffff8108e370>] ? __blocking_notifier_call_chain+0x60/0x90 [<ffffffff8108e3b6>] ? blocking_notifier_call_chain+0x16/0x20 [<ffffffff812f570c>] ? __device_release_driver+0xbc/0xe0 [<ffffffff812f5808>] ? driver_detach+0xd8/0xe0 [<ffffffff812f45d1>] ? bus_remove_driver+0x91/0x100 [<ffffffff812f6022>] ? driver_unregister+0x62/0xa0 [<ffffffff8123d5d4>] ? pci_unregister_driver+0x44/0xa0 [<ffffffffa05632d1>] ? iwl_exit+0x15/0x1c [iwlagn] [<ffffffff810ab492>] ? sys_delete_module+0x1a2/0x270 [<ffffffff81498da9>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8100bf42>] ? system_call_fastpath+0x16/0x1b I still can observe above warning after apply patch, but it is very hard to reproduce it, and have count=1. Whereas that one is easy to reproduce using debugfs force_reset while transmitting data, and have very big counts eg. 240, like quoted here. So count=1 WARNING seems to be different issue that need to be resolved separately. v1 -> v2: fix infinity loop bug I made during "for" to "while" loop transition. v2 -> v3: remove unneeded EXPORT_SYMBOL Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
AR9485 doesn't use the default GPIO pin for LED and GPIO 6 is actually used for this. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
If the RSSI calibration table was not found or not parsed properly, priv->rssi_db will be NULL, p54_rssi_find needs to be able to deal with that. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Acked-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Alessio Igor Bogani 提交于
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c: In function ‘rtl92ce_rx_query_desc’: drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:255:5: warning: ‘rf_rx_num’ may be used uninitialized in this function drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:257:12: warning: ‘total_rssi’ may be used uninitialized in this function drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:466:6: warning: ‘weighting’ may be used uninitialized in this function This work was supported by a hardware donation from the CE Linux Forum. Signed-off-by: NAlessio Igor Bogani <abogani@kernel.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Alessio Igor Bogani 提交于
=================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- net/mac80211/sta_info.c:125 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 5 locks held by wpa_supplicant/468: #0: (rtnl_mutex){+.+.+.}, at: [<c1465d84>] rtnl_lock+0x14/0x20 #1: (&rdev->mtx){+.+.+.}, at: [<f84b8c2b>] cfg80211_mgd_wext_siwfreq+0x6b/0x170 [cfg80211] #2: (&rdev->devlist_mtx){+.+.+.}, at: [<f84b8c37>] cfg80211_mgd_wext_siwfreq+0x77/0x170 [cfg80211] #3: (&wdev->mtx){+.+.+.}, at: [<f84b8c44>] cfg80211_mgd_wext_siwfreq+0x84/0x170 [cfg80211] #4: (&rtlpriv->locks.conf_mutex){+.+.+.}, at: [<f8506476>] rtl_op_bss_info_changed+0x26/0xc10 [rtlwifi] stack backtrace: Pid: 468, comm: wpa_supplicant Not tainted 2.6.38-rc6+ #79 Call Trace: [<c108806a>] ? lockdep_rcu_dereference+0xaa/0xb0 [<f8523d2c>] ? sta_info_get_bss+0x19c/0x1b0 [mac80211] [<f8523d62>] ? ieee80211_find_sta+0x22/0x40 [mac80211] [<f850661c>] ? rtl_op_bss_info_changed+0x1cc/0xc10 [rtlwifi] [<c153671c>] ? __mutex_unlock_slowpath+0x14c/0x160 [<c153673d>] ? mutex_unlock+0xd/0x10 [<f8507180>] ? rtl_op_config+0x120/0x310 [rtlwifi] [<c10896db>] ? trace_hardirqs_on+0xb/0x10 [<f8522169>] ? ieee80211_bss_info_change_notify+0xf9/0x1f0 [mac80211] [<f8506450>] ? rtl_op_bss_info_changed+0x0/0xc10 [rtlwifi] [<f853646f>] ? ieee80211_set_channel+0xbf/0xd0 [mac80211] [<f84b5f41>] ? cfg80211_set_freq+0x121/0x180 [cfg80211] [<f85363b0>] ? ieee80211_set_channel+0x0/0xd0 [mac80211] [<f84b8ceb>] ? cfg80211_mgd_wext_siwfreq+0x12b/0x170 [cfg80211] [<f84b87eb>] ? cfg80211_wext_siwfreq+0x9b/0x100 [cfg80211] [<c153b98b>] ? sub_preempt_count+0x7b/0xb0 [<c150f874>] ? ioctl_standard_call+0x74/0x3b0 [<c1465d84>] ? rtnl_lock+0x14/0x20 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211] [<c14568bd>] ? __dev_get_by_name+0x8d/0xb0 [<c150fddb>] ? wext_handle_ioctl+0x16b/0x180 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211] [<c145bc7a>] ? dev_ioctl+0x5ba/0x720 [<c108a947>] ? __lock_acquire+0x3e7/0x19b0 [<c1443b0b>] ? sock_ioctl+0x1eb/0x290 [<c108bfa5>] ? lock_release_non_nested+0x95/0x2f0 [<c1443920>] ? sock_ioctl+0x0/0x290 [<c114d74d>] ? do_vfs_ioctl+0x7d/0x5c0 [<c1112232>] ? might_fault+0x62/0xb0 [<c113e3c6>] ? fget_light+0x226/0x390 [<c1112278>] ? might_fault+0xa8/0xb0 [<c114dd17>] ? sys_ioctl+0x87/0x90 [<c1002f9f>] ? sysenter_do_call+0x12/0x38 This work was supported by a hardware donation from the CE Linux Forum. Signed-off-by: NAlessio Igor Bogani <abogani@kernel.org> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dan Carpenter 提交于
rate_mask is initialized again later so this can be removed. Btw, if rate_control_send_low(sta, priv_sta, txrc) returns false, that means that "sta" is non-NULL. That's why the second initialization of rate_mask is a little simpler than the first. Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Gustavo F. Padovan 提交于
If we want something "bool" built-in in something "tristate" it can't "depend on" the tristate config option. Report by DaveM: I give it 'y' just to make it happen, for both, and afterways no matter how many times I rerun "make oldconfig" I keep seeing things like this in my build: scripts/kconfig/conf --silentoldconfig Kconfig include/config/auto.conf:986:warning: symbol value 'm' invalid for BT_SCO include/config/auto.conf:3156:warning: symbol value 'm' invalid for BT_L2CAP Reported-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
Merge branch 'wireless-next-2.6' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6
-
由 John W. Linville 提交于
CC [M] drivers/net/wireless/at76c50x-usb.o drivers/net/wireless/at76c50x-usb.c: In function ‘at76_mac80211_tx’: drivers/net/wireless/at76c50x-usb.c:1759:4: warning: ‘return’ with a value, in function returning void This is fallout from commit 7bb45683 ("mac80211: make tx() operation return void"). Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 2月, 2011 5 次提交
-
-
由 Wey-Yi Guy 提交于
For 2000 series device, use session 2 type of BT UART message Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
Both inquiry and page was combine in frame7 of UART message, separate it Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
additional UART message defines Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
2000 series has different bt config command structure, add support for it Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
由 Wey-Yi Guy 提交于
No functional changes, name changes to reflect the structure used by 6000 series. Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
-
- 26 2月, 2011 14 次提交
-
-
由 John W. Linville 提交于
drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x29f0): multiple definition of `iwl_rates' drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0xa68): first defined here powerpc64-linux-ld: Warning: size of symbol `iwl_rates' changed from 143 in drivers/net/wireless/iwlwifi/built-in.o to 130 in drivers/net/wireless/iwlegacy/built-in.o drivers/net/wireless/iwlegacy/built-in.o:(.data+0x0): multiple definition of `bt_coex_active' drivers/net/wireless/iwlwifi/built-in.o:(.data+0x668): first defined here drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x750): multiple definition of `iwl_eeprom_band_1' drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0x27d0): first defined here drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x3f0): multiple definition of `iwl_bcast_addr' drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0x24f8): first defined here drivers/net/wireless/iwlegacy/built-in.o:(.bss+0x3d48): multiple definition of `iwl_debug_level' drivers/net/wireless/iwlwifi/built-in.o:(.bss+0x21950): first defined here Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
For devices supported by iwlwifi sometimes off-channel transmissions need to be handled by the device completely. To support this mac80211 needs to pass the frame directly to the driver and not through the TX path as the driver needs the frame and channel information at the same time. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Is still possible to schedule conn_mon_timer after disassociate from ieee80211_sta_tx_notify() and ieee80211_offchannel_ps_disable(). Move disassociate check to ieee80211_sta_reset_conn_monitor() to cover all these cases, and add unlikely since in most the time we call ieee80211_sta_reset_conn_monitor() when associated. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Initialize txq to avoid this warning: drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_flush’: drivers/net/wireless/ath/ath9k/main.c:2138: warning: ‘txq’ may be used uninitialized in this function Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
pll_work should be cancelled on full_sleep or it may cause redundant chip reset. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Vivek Natarajan 提交于
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
This patch fixes tramissing on OFDM rates for PHYs 1 and 2. There is still something wrong with PHYs 3+. Tests has shown decreasing of performance on CCK rates by 1-2%, we have to live with that. Additionaly this noticeably reduces amount of PHY errors. They were mostly produced by auto-switching to higher rate for better performanced, which resulted in no transmit at all and PHY errors. Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
This function was intended to calculate the number of RX chains needed, but could only work where the AP's streams were asymmetric, i.e. 2 TX and 3 RX or similar. In the case where IEEE80211_HT_MCS_TX_RX_DIFF was not set, this function would calculate the wrong information. Additionally, mac80211 didn't pass through the required values at all, so it couldn't work anyway. Rewrite the logic in this function and add appropriate comments to make it readable. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
We need to copy this to allow drivers to look at the information where needed. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Gunn 提交于
If the frequency can not be mapped to a channel structure log it and drop it. Signed-off-by: NJoseph J. Gunn <armadefuego@yahoo.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
This reverts 4a332a38 ("mac80211: Give it some time to do the TSF sync"). There's no point in waiting with a new IBSS merge just because the hardware hasn't merged up with the old IBSS yet, and since 34e8f082 we no longer attempt to merge with the IBSS we're already in. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The return value of the tx operation is commonly misused by drivers, leading to errors. All drivers will drop frames if they fail to TX the frame, and they must also properly manage the queues (if they didn't, mac80211 would already warn). Removing the ability for drivers to return a BUSY value also allows significant cleanups of the TX TX handling code in mac80211. Note that this also fixes a bug in ath9k_htc, the old "return -1" there was wrong. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k] Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00] Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi] Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx] Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Same fix as f844a709 "iwlwifi: do not set tx power when channel is changing". Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
The callback sets slot time as specified in IEEE 802.11-2007 section 17.3.8.6 and raises round trip delay accordingly. Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 2月, 2011 1 次提交
-
-
由 Johannes Berg 提交于
On my G5 this fails to compile with drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c:701: error: __ksymtab__rtl92c_phy_txpwr_idx_to_dbm causes a section type conflict drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c:701: error: __ksymtab__rtl92c_phy_txpwr_idx_to_dbm causes a section type conflict drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c:677: error: __ksymtab__rtl92c_phy_dbm_to_txpwr_Idx causes a section type conflict drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c:677: error: __ksymtab__rtl92c_phy_dbm_to_txpwr_Idx causes a section type conflict since you can't export static functions. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 24 2月, 2011 4 次提交
-
-
由 Larry Finger 提交于
As noted by Stephan Rothwell, an allyesconfig build fails since rtl8192cu was merged with failures such as: drivers/net/wireless/rtlwifi/rtl8192cu/built-in.o: In function `rtl92c_phy_sw_chnl': (.opd+0xf30): multiple definition of `rtl92c_phy_sw_chnl' drivers/net/wireless/rtlwifi/rtl8192ce/built-in.o:(.opd+0xb70): first defined here drivers/net/wireless/rtlwifi/rtl8192cu/built-in.o: In function `rtl92c_fill_h2c_cmd': (.opd+0x288): multiple definition of `rtl92c_fill_h2c_cmd' drivers/net/wireless/rtlwifi/rtl8192ce/built-in.o:(.opd+0x288): first defined here These are caused because the code shared between rtl8192ce and rtl8192cu is included in both drivers. This has been fixed by creating a new modue that contains the shared code. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Willy Tarreau 提交于
On ARM, compilation of rtlwifi/efuse.c fails with the message: ERROR: "__bad_udelay" [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined! On inspection, the faulty calls are in routine efuse_reset_loader(), a routine that is never used, and the faulty routine is deleted. Signed-off-by: NWilly Tarreau <w@1wt.eu> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Willy Tarreau 提交于
On systems where PCI does not exist, a build of rtlwifi will fail. Apply the same fix in case there are systems with PCI but not USB. Signed-off-by: NWilly Tarreau <w@1wt.eu> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Willy Tarreau 提交于
On the ARM system, a build fails due to missing include. Signed-off-by: NWilly Tarreau <w@1wt.eu> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-