- 16 Aug, 2010 29 commits
-
-
Johannes Berg authored
Only the IBSS manager, ie. the station that sent the IBSS beacon last, should be replying to probe responses. This requires implementing the mac80211 tx_last_beacon callback, which we can do thanks to the ucode beacon notification. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
iwl_set_hw_params() only used by _agn, make it static Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
Log the information after reading the PCI_REVISION_ID from pci config space, Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
iwl_hw_detect() only used by _agn, make it static Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Thomas Klute authored
Split some long lines to make checkpatch.pl happy. ;-) Signed-off-by: Thomas Klute <thomas2.klute@uni-dortmund.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Thomas Klute authored
Signed-off-by: Thomas Klute <thomas2.klute@uni-dortmund.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Having both scan and work mutexes is not just a bit too fine grained, it also creates issues when there's code that needs both since they then need to be acquired in the right order, which can be hard to do. Therefore, use just a single mutex for both. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
We do not need export iwl_bg.*scan.*() functions just for initialize workqueue in other module. Making that functions static helps with iwl-scan.c code review a bit. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Frames that failed PLCP error checks are most likely microwave transmissions (well, maybe not ...) and don't have a proper rate detected, so ignore it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Williams authored
Bring back the comment about FW v5 status codes from the pre-cfg80211 driver, and let through status codes that aren't remapped by the firmware. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Williams authored
Make it a bit easier to debug scan results in the future. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This helps us debug channel changes better. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When running in client mode and associating to an AP, the channel change is usually performed with the offchannel flag still set. However after the assoc is complete, the following channel change event is suppressed because the run time channel is already set to the operating channel. Fix this by sending channel change notifications to the driver even if only the offchannel flag changes. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This function was exiting early if the existing diversity settings were unchanged. Unfortunately, in some cases the antenna configuration is not initialized at all. https://bugzilla.kernel.org/show_bug.cgi?id=14751Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com>
-
John W. Linville authored
...and unregistration to core shutdown. Previously, the driver remained registered even when the hardware was shutdown. That causes the driver to return -ENODEV if the b43 device is IFF_DOWN. This change causes the driver to disappear in that case, allowing /dev/hwrng to still function if another hwrng device is available. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
drivers/net/wireless/iwmc3200wifi/rx.c: In function 'iwm_ntf_wifi_if_wrapper': drivers/net/wireless/iwmc3200wifi/rx.c:1198: warning: comparison is always true due to limited range of data type This is, of course, because the value of WIFI_IF_NTFY_MAX is 0xff and hdr->oid is a u8. This is obviously an attempt to verify the range on an input value, but since it has no effect it can simply be removed. Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Samuel Ortiz <samuel.ortiz@intel.com>
-
John W. Linville authored
drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_tx_send_commands': drivers/net/wireless/ipw2x00/ipw2100.c:3063: warning: cast to pointer from integer of different size This changes the cast and the conversion to match other usage of the same value in calls to IPW_DEBUG_TX. Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Some iwlwifi devices inexplicably disconnect themselves from the PCI-E bus causing the predictable failures. This seems to disappear if ASPM is disabled. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This provides a little more flexibility for human users, and it allows us to use isalpha rather than the custom is_alpha_upper. 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
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
This patch implement basic infrastructure to support use of NAPI by mac80211-based hardware drivers. Because mac80211 devices can support multiple netdevs, a dummy netdev is used for interfacing with the NAPI code in the core of the network stack. That structure is hidden from the hardware drivers, but the actual napi_struct is exposed in the ieee80211_hw structure so that the poll routines in drivers can retrieve that structure. Hardware drivers can also specify their own weight value for NAPI polling. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 13 Aug, 2010 4 commits
-
-
Maxim Levitsky authored
Atheros PCIe wireless cards handled by ath5k do require L0s disabled. For distributions shipping with CONFIG_PCIEASPM (this will be enabled by default in the future in 2.6.36) this will also mean both L1 and L0s will be disabled when a pre 1.1 PCIe device is detected. We do know L1 works correctly even for all ath5k pre 1.1 PCIe devices though but cannot currently undue the effect of a blacklist, for details you can read pcie_aspm_sanity_check() and see how it adjusts the device link capability. It may be possible in the future to implement some PCI API to allow drivers to override blacklists for pre 1.1 PCIe but for now it is best to accept that both L0s and L1 will be disabled completely for distributions shipping with CONFIG_PCIEASPM rather than having this issue present. Motivation for adding this new API will be to help with power consumption for some of these devices. Example of issues you'd see: - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well with ASPM enabled, the card will eventually stall on heavy traffic with often 'unsupported jumbo' warnings appearing. Disabling ASPM L0s in ath5k fixes these problems. - On the same card you would see a storm of RXORN interrupts even though medium is idle. Credit for root causing and fixing the bug goes to Jussi Kivilinna. Cc: David Quan <David.Quan@atheros.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tim Gardner <tim.gardner@canonical.com> Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rajkumar Manoharan authored
This patch handles the firmware loading properly for device ID 7015. Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Yuri Kululin authored
Use appropriate command (CMD_TRIGGER_SCAN_TO) instead of scan command (CMD_SCAN) to configure trigger scan timeout. This was broken in commit 3a98c30f. This fix address the bug reported here: https://bugzilla.kernel.org/show_bug.cgi?id=16554 Cc: stable@kernel.org Signed-off-by: Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com> Acked-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vivek Natarajan authored
Some APs advertise that they may be HT40 capable in the capabilites but the current operating channel configuration may be only HT20. This causes disconnection as ath9k_htc sets WLAN_RC_40_FLAG despite the AP operating in HT20 mode. Hence set this flag only if the current channel configuration is HT40 enabled. Cc: stable@kernel.org Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 11 Aug, 2010 2 commits
-
-
Rajkumar Manoharan authored
This should fix the oops which occurs during the packet injection on monitor interface. EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc] [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211] [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc] [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211] [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211] [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211] [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211] [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210 [<c04b97c2>] ? __alloc_skb+0x52/0x130 [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170 [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0 [<c0567e1e>] ? packet_snd+0x21e/0x250 [<c05684a2>] ? packet_sendmsg+0x32/0x40 [<c04b4c63>] ? sock_aio_write+0x113/0x130 [<c0207934>] ? do_sync_write+0xc4/0x100 [<c0167740>] ? autoremove_wake_function+0x0/0x50 [<c02f4414>] ? security_file_permission+0x14/0x20 [<c0207ad4>] ? rw_verify_area+0x64/0xe0 [<c01e6458>] ? handle_mm_fault+0x338/0x390 [<c0207cd5>] ? vfs_write+0x185/0x1a0 [<c058db20>] ? do_page_fault+0x160/0x3a0 [<c0208512>] ? sys_write+0x42/0x70 [<c01033ec>] ? syscall_call+0x7/0xb Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
It is necessary to call pm_qos_add_request prior to calling pm_qos_update_request. It was revealed that ipw2100 has been doing this wrong since "pm_qos: Get rid of the allocation in pm_qos_add_request()" (commit 82f68251) added a WARN that results in the following backtrace: WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70() pm_qos_update_request() called for unknown object Call Trace: [<c1024088>] ? warn_slowpath_common+0x78/0xb0 [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70 [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70 [<c1024153>] ? warn_slowpath_fmt+0x33/0x40 [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70 [<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100] [<c11961c9>] ? vsnprintf+0xc9/0x530 [<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100] [<c12f542d>] ? register_netdevice+0x7d/0x3c0 [<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100] [<c12f579f>] ? register_netdev+0x2f/0x40 [<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100] [<c11a5ebb>] ? local_pci_probe+0xb/0x10 [<c11a6d49>] ? pci_device_probe+0x69/0x90 [<c1224704>] ? driver_probe_device+0x74/0x180 [<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0 [<c1224889>] ? __driver_attach+0x79/0x80 [<c1224810>] ? __driver_attach+0x0/0x80 [<c1223fa2>] ? bus_for_each_dev+0x52/0x80 [<c1224586>] ? driver_attach+0x16/0x20 [<c1224810>] ? __driver_attach+0x0/0x80 [<c122395f>] ? bus_add_driver+0x17f/0x250 [<c11a5ec0>] ? pci_device_shutdown+0x0/0x20 [<c11a6c80>] ? pci_device_remove+0x0/0x40 [<c1224b13>] ? driver_register+0x63/0x120 [<c11a6f96>] ? __pci_register_driver+0x36/0xa0 [<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100] [<c1001122>] ? do_one_initcall+0x32/0x170 [<c1087078>] ? __vunmap+0xb8/0xf0 [<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100] [<c10510c1>] ? sys_init_module+0x161/0x1000 [<c108f847>] ? sys_close+0x67/0xe0 [<c13647c1>] ? syscall_call+0x7/0xb This patch moves pm_qos_add_request prior to pci_register_driver in ipw2100 in order to avoid this problem. Reported-by: Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 10 Aug, 2010 5 commits
-
-
Mat Martineau authored
The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on the default L2CAP MTU. That default MTU is calculated from the size of two DH5 packets, minus ACL and L2CAP b-frame header overhead. ERTM is used with newer basebands that typically support larger 3-DH5 packets, and i-frames and s-frames have more header overhead. With clean RF conditions, basebands will typically attempt to use 1021-byte 3-DH5 packets for maximum throughput. Adjusting for 2 bytes of ACL headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes of payload. This PDU size imposes less overhead for header bytes and gives the baseband the option to choose 3-DH5 packets, but is small enough for ERTM traffic to interleave well with other L2CAP or SCO data. 672-byte payloads do not allow the most efficient over-the-air packet choice, and cannot achieve maximum throughput over BR/EDR. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Mat Martineau authored
remote_tx_win is intended to be set on receipt of an L2CAP configuration request. The value is used to determine the size of the transmit window on the remote side of an ERTM connection, so L2CAP can stop sending frames when that remote window is full. An incorrect remote_tx_win value will cause the stack to not fully utilize the tx window (performance impact), or to overfill the remote tx window (causing dropped frames or a disconnect). This patch removes an extra setting of remote_tx_win when a configuration response is received. The transmit window has a different meaning in a response - it is an informational value less than or equal to the local tx_win. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Mat Martineau authored
The L2CAP specification requires that the ERTM retransmit timeout be at least 2 seconds for BR/EDR connections. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Mat Martineau authored
Incoming configuration values must be converted to native CPU order before use. This fixes a bug where a little-endian MPS value is compared to a native CPU value. On big-endian processors, this can cause ERTM and streaming mode segmentation to produce PDUs that are larger than the remote stack is expecting, or that would produce fragmented skbs that the current FCS code cannot handle. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>