summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* iwlagn: Fix a bug introduced by the HUGE command removalEmmanuel Grumbach2011-06-241-6/+1
| | | | | | | | | | | | | Since we don't have HUGE command any more, there is no point in adding 1 to the num of slots in the command queue. Doing so is buggy and might corrupt memory. Bug introduced by 4ce7cc2b09553a91d4aea014c39674685715173a iwlagn: support multiple TBs per command Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
* mwl8k: Tell firmware to generate CCMP headerNishant Sarmukadam2011-06-151-1/+3
| | | | | | | | | | Post commit e4eefec73ea0a740bfe8736e3ac30dfe92fe392b, the stack is not generating the CCMP header for us anymore. This broke the CCMP functionality since firmware was not doing this either. Set a flag to tell the firmware to generate the CCMP header Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mwifiex: Fixing NULL pointer dereferenceYogesh Ashok Powar2011-06-151-0/+2
| | | | | | | | | | | | | | | | | | Following OOPS was seen when booting with card inserted BUG: unable to handle kernel NULL pointer dereference at 0000004c IP: [<f8b7718c>] cfg80211_get_drvinfo+0x21/0x115 [cfg80211] *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: iwl3945 iwl_legacy mwifiex_sdio mac80211 11 sdhci_pci sdhci pl2303 'ethtool' on the mwifiex device returned this OOPS as wiphy_dev() returned NULL. Adding missing set_wiphy_dev() call to fix the problem. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'master' of ↵John W. Linville2011-06-105-9/+36
|\ | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-2.6
| * Bluetooth: Do not send SET_EVENT_MASK for 1.1 and earlier devicesVille Tervo2011-06-101-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some old hci controllers do not accept any mask so leave the default mask on for these devices. < HCI Command: Set Event Mask (0x03|0x0001) plen 8 Mask: 0xfffffbff00000000 > HCI Event: Command Complete (0x0e) plen 4 Set Event Mask (0x03|0x0001) ncmd 1 status 0x12 Error: Invalid HCI Command Parameters Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Tested-by: Corey Boyle <corey@kansanian.com> Tested-by: Ed Tomlinson <edt@aei.ca> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: Do not ignore errors returned from strict_strtol()David Miller2011-06-101-0/+12
| | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: fix shutdown on SCO socketsLuiz Augusto von Dentz2011-06-101-1/+12
| | | | | | | | | | | | | | | | | | | | shutdown should wait for SCO link to be properly disconnected before detroying the socket, otherwise an application using the socket may assume link is properly disconnected before it really happens which can be a problem when e.g synchronizing profile switch. Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
| * Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.Filip Palian2011-06-092-0/+2
| | | | | | | | | | | | | | | | | | Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding byte each. This byte in "cinfo" is copied to userspace uninitialized. Signed-off-by: Filip Palian <filip.palian@pjwstk.edu.pl> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
* | iwlegacy: fix channel switch lockingStanislaw Gruszka2011-06-085-46/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We use priv->mutex to avoid race conditions between chswitch_done() and mac_channel_switch(), when marking channel switch in progress. But chswitch_done() can be called in atomic context from rx_csa() or with mutex already taken from commit_rxon(). To fix remove mutex from chswitch_done() and use atomic bitops for marking channel switch pending. Cc: stable@kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: fix IBSS teardown raceJohannes Berg2011-06-081-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ignacy reports that sometimes after leaving an IBSS joining a new one didn't work because there still were stations on the list. He fixed it by flushing stations when attempting to join a new IBSS, but this shouldn't be happening in the first case. When I looked into it I saw a race condition in teardown that could cause stations to be added after flush, and thus cause this situation. Ignacy confirms that after applying my patch he hasn't seen this happen again. Reported-by: Ignacy Gawedzki <i@lri.fr> Debugged-by: Ignacy Gawedzki <i@lri.fr> Tested-by: Ignacy Gawedzki <i@lri.fr> Cc: stable@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlagn: send tx power command if defer cause by RXON not matchWey-Yi Guy2011-06-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | During channge channel, tx power will not send to uCode, the tx power command should send after scan complete. but should also can send after RXON command. Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Cc: stable@kernel.org [2.6.38+] Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | nl80211: fix overflow in ssid_lenLuciano Coelho2011-06-071-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When one of the SSID's length passed in a scan or sched_scan request is larger than 255, there will be an overflow in the u8 that is used to store the length before checking. This causes the check to fail and we overrun the buffer when copying the SSID. Fix this by checking the nl80211 attribute length before copying it to the struct. This is a follow up for the previous commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem entirely. Reported-by: Ido Yariv <ido@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rtlwifi: Avoid modifying skbs that are resubmittedMike McCormack2011-06-071-15/+13
| | | | | | | | | | | | | | | | | | | | | | In the case we fail to allocate a new skb, the old skb should be resubmitted unmodified. Fixes bug introduced in a9e12869758430424804. Signed-off-by: Mike McCormack <mikem@ring3k.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | rtlwifi: Fix logic in rx_interruptMike McCormack2011-06-071-1/+1
| | | | | | | | | | | | | | | | Should pass along packet if there's no CRC and no hardware error. Signed-off-by: Mike McCormack <mikem@ring3k.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | Revert "mac80211: stop queues before rate control updation"John W. Linville2011-06-071-6/+0
|/ | | | | | | | | | This reverts commit 1d38c16ce4156f63b45abbd09dd28ca2ef5172b4. The mac80211 maintainer raised complaints about abuse of the CSA stop reason, and about whether this patch actually serves its intended purpose at all. Signed-off-by: John W. Linville <linville@tuxdriver.com>
* iwl4965: set tx power after rxon_assocStanislaw Gruszka2011-06-061-1/+2
| | | | | | | | | | | | | | | Setting tx power can be deferred during scan or changing channel. If after that correct tx power settings will not be sent to device, we can observe transmission problems and timeouts. Force to send tx power settings also after partial rxon change, to assure device always be configured with up-to-date settings. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=36492 Cc: stable@kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: fix rmmod crashStanislaw Gruszka2011-06-062-1/+6
| | | | | | | | | | | | | | | Avoid queue and run autowakeup_work when device is not present anymore. That prevent rmmod and device remove crash introduced by: commit 1c0bcf89d85cc97a0d9ce4cd909351a81fa4fdde Author: Ivo van Doorn <ivdoorn@gmail.com> Date: Sat Apr 30 17:18:18 2011 +0200 rt2x00: Add autowake support for USB hardware Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* iwlagn: use cts-to-self protection on 5000 adapters seriesStanislaw Gruszka2011-06-063-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes 802.11n stability and performance regression we have since 2.6.35. It boost performance on my 5GHz N-only network from about 5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz. These are test results of 5x downloading of approximately 700MB iso image: vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110 patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946 This was achieved with NetworkManager configured to do not perform periodical scans, by configuring constant BSSID. With periodical scans, after some time, performance downgrade to unpatched driver level, like in example below: patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683 However patch still make better here, since similar test on unpatched driver make link disconnects with below messages after some time: wlan1: authenticate with 00:23:69:35:d1:3f (try 1) wlan1: authenticate with 00:23:69:35:d1:3f (try 2) wlan1: authenticate with 00:23:69:35:d1:3f (try 3) wlan1: authentication with 00:23:69:35:d1:3f timed out On 2.6.35 kernel patch helps against connection hangs with messages: iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload. iwlagn 0000:20:00.0: On demand firmware reload iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting Cc: stable@kernel.org # 2.6.35+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Revert "mac80211: Skip tailroom reservation for full HW-crypto devices"John W. Linville2011-06-063-23/+8
| | | | | | | | | | | | | | | This reverts commit aac6af5534fade2b18682a0b9efad1a6c04c34c6. Conflicts: net/mac80211/key.c That commit has a race that causes a warning, as documented in the thread here: http://marc.info/?l=linux-wireless&m=130717684914101&w=2 Signed-off-by: John W. Linville <linville@tuxdriver.com>
* libertas_sdio: handle spurious interruptsDaniel Drake2011-06-031-5/+16
| | | | | | | | | | | | | | | | | | | Commit 06e8935febe687e2a561707d4c7ca4245d261dbe adds an IRQ handling optimization for single-function SDIO cards like this one, but at the same time exposes a small hardware bug. During hardware init, an interrupt is generated with (apparently) no source. Previously, mmc threw this interrupt away, but now (due to the optimization), the mmc layer passes this onto libertas, before it is ready (and before it has enabled interrupts), causing a crash. Work around this hardware bug by registering the IRQ handler later and making it capable of handling interrupts with no cause. The change that makes the IRQ handler registration happen later actually eliminates the spurious interrupt as well. Signed-off-by: Daniel Drake <dsd@laptop.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: call dev_alloc_name before copying name to sdataThadeu Lima de Souza Cascardo2011-06-031-0/+4
| | | | | | | | | | | | | | | This partially reverts 1c5cae815d19ffe02bdfda1260949ef2b1806171, because the netdev name is copied into sdata->name, which is used for debugging messages, for example. Otherwise, we get messages like this: wlan%d: authenticated Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Cc: Jiri Pirko <jpirko@redhat.com> Cc: David S. Miller <davem@davemloft.net> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "John W. Linville" <linville@tuxdriver.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* iwlagn: fix channel switch lockingStanislaw Gruszka2011-06-039-119/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | We use priv->mutex to avoid race conditions between iwl_chswitch_done() and iwlagn_mac_channel_switch(), when marking channel switch in progress. But iwl_chswitch_done() can be called in atomic context from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon(). These bugs were introduced by: commit 79d07325502e73508f917475bc1617b60979dd94 Author: Wey-Yi Guy <wey-yi.w.guy@intel.com> Date: Thu May 6 08:54:11 2010 -0700 iwlwifi: support channel switch offload in driver To fix remove mutex from iwl_chswitch_done() and use atomic bitops for marking channel switch pending. Also remove iwl2030_hw_channel_switch() since 2000 series adapters are 2.4GHz only devices. Cc: stable@kernel.org # 2.6.36+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath5k: Disable fast channel switching by defaultNick Kossifidis2011-06-032-2/+14
| | | | | | | | | | | Disable fast channel change by default on AR2413/AR5413 due to some bug reports (it still works for me but it's better to be safe). Add a module parameter "fastchanswitch" in case anyone wants to enable it and play with it. Signed-off-by: Nick Kossifidis <mickflemm@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ssb: fix PCI(e) driver regression causing oops on PCI cardsRafał Miłecki2011-06-031-4/+6
| | | | | | | | | | | | We were incorrectly executing PCIe specific workarounds on PCI cards. This resulted in: Machine check in kernel mode. Caused by (from SRR1=149030): Transfer error ack signal Oops: Machine check, sig: 7 [#1] Reported-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* iwl4965: correctly validate temperature valueStanislaw Gruszka2011-06-011-1/+1
| | | | | | | | | | | | | In some cases we can read wrong temperature value. If after that temperature value will not be updated to good one, we badly configure tx power parameters and device is unable to send a data. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=35932 Cc: stable@kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bluetooth l2cap: fix locking in l2cap_global_chan_by_psmJohannes Berg2011-06-011-1/+1
| | | | | | | | | | | | | | read_lock() ... read_unlock_bh() is clearly bogus. This was broken by commit 23691d75cdc69c3b285211b4d77746aa20a17d18 Author: Gustavo F. Padovan <padovan@profusion.mobi> Date: Wed Apr 27 18:26:32 2011 -0300 Bluetooth: Remove l2cap_sk_list Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: fix two more bugs in tx powerDaniel Halperin2011-06-012-4/+16
| | | | | | | | | | | | | | | | | | | This is the same fix as commit 841051602e3fa18ea468fe5a177aa92b6eb44b56 Author: Matteo Croce <technoboy85@gmail.com> Date: Fri Dec 3 02:25:08 2010 +0100 The ath9k driver subtracts 3 dBm to the txpower as with two radios the signal power is doubled. The resulting value is assigned in an u16 which overflows and makes the card work at full power. in two more places. I grepped the ath tree and didn't find any others. Cc: stable@kernel.org Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211: don't drop p2p probe responsesEliad Peller2011-06-012-21/+30
| | | | | | | | | | | | | | | Commit 0a35d36 ("cfg80211: Use capability info to detect mesh beacons") assumed that probe response with both ESS and IBSS bits cleared means that the frame was sent by a mesh sta. However, these capabilities are also being used in the p2p_find phase, and the mesh-validation broke it. Rename the WLAN_CAPABILITY_IS_MBSS macro, and verify that mesh ies exist before assuming this frame was sent by a mesh sta. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* iwlagn: fix incorrect PCI subsystem id for 6150 devicesWey-Yi Guy2011-05-313-13/+22
| | | | | | | | For 6150 devices, modify the supported PCI subsystem ID. Cc: stable@kernel.org Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* zd1211rw: fix to work on OHCIJussi Kivilinna2011-05-311-11/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 However on USB 1.1 endpoint becomes Bulk: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Commit 37939810b937aba830dd751291fcdc51cae1a6cb assumed that endpoint is always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg(). Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the call and changes requested pipe to interrupt type (see usb_bulk_msg). However with usb_interrupt_msg() on bulk endpoint does not correct the pipe type to bulk, but instead URB is submitted with interrupt type pipe. So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw from working with OHCI. Fix this by detecting endpoint type and using correct endpoint/pipe types for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right URB type on 'EP 4 OUT'. Cc: stable@kernel.org Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* wl12xx: fix oops in sched_scan when forcing a passive scanLuciano Coelho2011-05-311-3/+8
| | | | | | | | | | | | | | | | Fix kernel oops when trying to use passive scheduled scans. The reason was that in passive scans there are no SSIDs, so there was a NULL pointer dereference. To solve the problem, we now check the number of SSIDs provided in the sched_scan request and only access the list if there's one or more (ie. passive scan is not forced). We also force all the channels to be passive by adding the IEEE80211_CHAN_PASSIVE_SCAN flag locally before the checks in the wl1271_scan_get_sched_scan_channels() function. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* wl12xx: add separate config value for DFS dwell time on sched scanLuciano Coelho2011-05-313-2/+9
| | | | | | | | | | | | | Use a different value for DFS dwell time when performing a scheduled scan. Previously we were using the same value as for normal passive scans. This adds some flexibility between these two different types of passive scan. For now we use 150 TUs for DFS channel dwell time. This may need to be fine-tuned in the future. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* wl12xx: fix DFS channels handling in scheduled scanLuciano Coelho2011-05-312-11/+23
| | | | | | | | | | | | | DFS channels were never getting included in the scheduled scans, because they always contain the passive flag as well and the call was asking for DFS and active channels. Fix this by ignoring the passive flag when collecting DFS channels. Also, move the DFS channels in the channel list before the 5GHz active channels (this was implemented in the FW differently than specified). Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* wl12xx: fix passive and radar channel generation for scheduled scanLuciano Coelho2011-05-311-2/+2
| | | | | | | | | | We were comparing bitwise AND results with a boolean, so when the boolean was set to true, it was not matching as it should. Fix this by booleanizing the bitwise AND results with !!. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* libertas: Set command sequence number later to ensure consistencyDaniel Drake2011-05-311-3/+3
| | | | | | | | | | | | | | | | | Before this patch, the command sequence number is being set before lbs_queue_cmd() adds the command to the queue. However, lbs_queue_cmd() sometimes forces commands to queue-jump (e.g. CMD_802_11_WAKEUP_CONFIRM). It currently does this without considering that sequence numbers might need adjusting to keep things running in order. Fix this by setting the sequence number at a later stage, just before we're actually submitting the command to the hardware. Also fixes a possible race where seqnum was being modified outside of the driver lock. Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge ↵John W. Linville2011-05-2715-27/+70
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
| * ath9k: Fix AR9287 calibrationAdrian Chadd2011-05-271-1/+1
| | | | | | | | | | | | | | | | | | | | The AR9287 calibration code was not being called because of an incorrect MAC revision check. This forced the AR9287 to use the AR9285 initial calibration code and bypass the AR9287 code entirely. Signed-off-by: Adrian Chadd <adrian@freebsd.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: Remove duplicate linux/slab.h include from net/mac80211/scan.cJesper Juhl2011-05-271-1/+0
| | | | | | | | | | | | | | | | | | Commit 79f460ca49d8d5700756ab7071c951311c7f29cc add a duplicate linux/slab.h include to net/mac80211/scan.c - remove it. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: clear local->ps_data on disassocEliad Peller2011-05-271-0/+1
| | | | | | | | | | | | | | | | | | local->ps_data wasn't cleared on disassociation, which (in some corner cases) caused reconnections to enter psm before association completed. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * wireless: Default to 'n' for 2 new added devices in Kconfig.Tao Ma2011-05-272-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We make oldconfig every time when a new kernel arrives, but if we don't have such a device(I guess this is the most common case for a new device), the default value should be 'n' so that the kernel size we build doesn't grow up too much quickly. For anyone who has the device, it is OK for them to turn it on by themselves. Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Tao Ma <boyu.mt@taobao.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * iwl4965: fix 5GHz operationStanislaw Gruszka2011-05-271-2/+2
| | | | | | | | | | | | | | | | rx_status.band is used uninitialized, what disallow to work on 5GHz . Cc: stable@kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: stop queues before rate control updationRajkumar Manoharan2011-05-261-0/+6
| | | | | | | | | | | | | | | | | | Stop tx queues before updating rate control to ensure proper rate selection. Otherwise packets can be transmitted in 40 Mhz whereas hw is configured in HT20. Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k: set 40 Mhz rate only if hw is configured in ht40Rajkumar Manoharan2011-05-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever there is a channel width change from 40 Mhz to 20 Mhz, the hardware is reconfigured to ht20. Meantime before doing the rate control updation, the packets are being transmitted are selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH. While transmitting ht40 rate packets in ht20 mode is causing baseband panic with AR9003 based chips. ==== BB update: BB status=0x02001109 ==== ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2 src=0 ** ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 ** ath: ** BB mode: BB_gen_controls=0x000033c0 ** ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% ** ath: ==== BB update: done ==== Cc: stable@kernel.org Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k_hw: disable phy restart on baseband panic caused by RXSMRajkumar Manoharan2011-05-263-1/+28
| | | | | | | | | | | | | | | | | | | | While receiving unsupported rate frame rx state machine gets into a state 0xb and if phy_restart happens in that state, BB would go hang. If RXSM is in 0xb state after first bb panic, ensure to disable the phy_restart. Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k: Reset chip on baseband hangRajkumar Manoharan2011-05-261-1/+3
| | | | | | | | | | | | | | | | | | Resetting hardware helps to recover from baseband hang/panic for AR9003 based chips. Cc: stable@kernel.org Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * b43: N-PHY: initialize last var in calibration functionRafał Miłecki2011-05-261-1/+1
| | | | | | | | | | | | Reported-by: Larry Finger <larry.finger@lwfinger.net> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rtlwifi: Use order 2 RX buffer allocation only if necessaryLarry Finger2011-05-261-0/+7
| | | | | | | | | | | | | | | | | | | | Although a previous fix handles the kernel panics that result from failure to allocate a new RX buffer, memory fragmentation can be reduced if the amsdu_8k capability is disabled as new buffers need only be of O(0), not O(2). Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rtlwifi: Fix kernel panic resulting from RX buffer allocation failureLarry Finger2011-05-261-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To handle amsdu_8k capability, the PCI routine of this driver must allocate receive buffers of order 2. Under heavy load, this causes fragmentation of memory. The present code releases the current buffer before checking to see if a new one is availble. Recovery from allocation failures is not possible, which results in kernel panics. The fix is to reorder the code to check that a new buffer can be allocated before the old one is released. If not possible, the received frame is dropped and the old one is reused. Without this change, it is impossible to transfer a 2 GB file without a kernel panic. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [2.6.{37,38,39}] Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * nl80211: fix check for valid SSID size in scan operationsLuciano Coelho2011-05-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In both trigger_scan and sched_scan operations, we were checking for the SSID length before assigning the value correctly. Since the memory was just kzalloc'ed, the check was always failing and SSID with over 32 characters were allowed to go through. This was causing a buffer overflow when copying the actual SSID to the proper place. This bug has been there since 2.6.29-rc4. Cc: stable@kernel.org Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mwifiex: correct event header lengthYogesh Ashok Powar2011-05-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While decoding received event packet from firmware, 4 bytes of interface header are already removed unconditionally. So for handling event only 4 more bytes needs to be pulled. This is achieved by changing event header length to 4. Almost all the events, except BA stream related and AMSDU aggregation control events, do not have the payload in their event skb. Such events handling depends only on the event ID. This event ID is the first four bytes of the event skb, which is copied to a separate variable before pulling the skb header. Hence event handling worked only for those events that didn't have payload in event skb. This patch fixes the broken event path of the events with payload in their event skb without harming existing working event path for the events without payload. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Kiran Divekar <dkiran@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-30 20:10:15 +0100