aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge branch 'master' of ↵John W. Linville2013-01-28
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
| * Merge branch 'master' of ↵John W. Linville2013-01-28
| |\ | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/ath/ath9k/main.c drivers/net/wireless/iwlwifi/dvm/tx.c
| | * mwifiex: fix typo in PCIe adapter NULL checkAvinash Patil2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing "!" as we are supposed to check "!card->adapter" in PCIe suspend handler. Cc: "3.2+" <stable@vger.kernel.org> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Reviewed-by: Sergey V. <sftp.mtuci@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ath9k: allow setting arbitrary antenna masks on AR9003+Felix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ath9k_hw: fix chain swap setting when setting rx chainmask to 5Felix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Chain swapping should only be enabled when the EEPROM chainmask is set to 5, regardless of what the runtime chainmask is. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ath9k_hw: fix calibration issues on chainmask that don't include chain 0Felix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * rtlwifi: Fix build warning introduced by commit a290593Larry Finger2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kbuild test robot reports the following warning with x86_64-randconfig-x955: warning: (RTL8192CE && RTL8192SE && RTL8192DE && RTL8723AE && RTL8192CU) selects RTLWIFI which has unmet direct dependencies (NETDEVICES && WLAN && (RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE)) This warning was introduced in commit a290593, "rtlwifi: Modify files for addition of rtl8723ae", and is d ue to a missing dependence of RTLWIFI on RTL8723AE. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: kbuild test robot <fengguang.wu@intel.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * iwlegacy: fix IBSS cleanupStanislaw Gruszka2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do not correctly change interface type when switching from IBSS mode to STA mode, that results in microcode errors. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=886946 Reported-by: Jaroslav Skarvada <jskarvad@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * Merge branch 'for-john' of ↵John W. Linville2013-01-22
| | |\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
| | | * mac80211: add encrypt headroom to PERR framesBob Copeland2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mesh PERR action frames are robust and thus may be encrypted, so add proper head/tailroom to allow this. Fixes this warning when operating a Mesh STA on ath5k: WARNING: at net/mac80211/wpa.c:427 ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]() Call Trace: [<c011c5e7>] warn_slowpath_common+0x63/0x78 [<c011c60b>] warn_slowpath_null+0xf/0x13 [<e090621d>] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211] [<e090685c>] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 [mac80211] [<e0917113>] invoke_tx_handlers+0xcad/0x10bd [mac80211] [<e0917665>] ieee80211_tx+0x87/0xb3 [mac80211] [<e0918932>] ieee80211_tx_pending+0xcc/0x170 [mac80211] [<c0121c43>] tasklet_action+0x3e/0x65 Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | | * mac80211: set NEED_TXPROCESSING for PERR framesBob Copeland2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A user reported warnings in ath5k due to transmitting frames with no rates set up. The frames were Mesh PERR frames, and some debugging showed an empty control block with just the vif pointer: > [ 562.522682] XXX txinfo: 00000000: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 ................ > [ 562.522688] XXX txinfo: 00000010: 00 00 00 00 00 00 00 00 54 b8 f2 > db 00 00 00 00 ........T....... > [ 562.522693] XXX txinfo: 00000020: 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 ................ Set the IEEE80211_TX_INTFL_NEED_TXPROCESSING flag to ensure that rate control gets run before the frame is sent. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | | * mac80211: fix monitor mode injectionFelix Fietkau2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Channel contexts are not always used with monitor interfaces. If no channel context is set, use the oper channel, otherwise tx fails. Signed-off-by: Felix Fietkau <nbd@openwrt.org> [check local->use_chanctx] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | | * mac80211: synchronize scan off/on-channel and PS statesStanislaw Gruszka2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since: commit b23b025fe246f3acc2988eb6d400df34c27cb8ae Author: Ben Greear <greearb@candelatech.com> Date: Fri Feb 4 11:54:17 2011 -0800 mac80211: Optimize scans on current operating channel. we do not disable PS while going back to operational channel (on ieee80211_scan_state_suspend) and deffer that until scan finish. But since we are allowed to send frames, we can send a frame to AP without PM bit set, so disable PS on AP side. Then when we switch to off-channel (in ieee80211_scan_state_resume) we do not enable PS. Hence we are off-channel with PS disabled, frames are not buffered by AP. To fix remove offchannel_ps_disable argument and always enable PS when going off-channel and disable it when going on-channel, like it was before. Cc: stable@vger.kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | | * mac80211: fix FT roamingJohannes Berg2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During FT roaming, wpa_supplicant attempts to set the key before association. This used to be rejected, but as a side effect of my commit 66e67e418908442389d3a9e ("mac80211: redesign auth/assoc") the key was accepted causing hardware crypto to not be used for it as the station isn't added to the driver yet. It would be possible to accept the key and then add it to the driver when the station has been added. However, this may run into issues with drivers using the state- based station adding if they accept the key only after association like it used to be. For now, revert to the behaviour from before the auth and assoc change. Cc: stable@vger.kernel.org Reported-by: Cédric Debarge <cedric.debarge@acksys.fr> Tested-by: Cédric Debarge <cedric.debarge@acksys.fr> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * | Merge branch 'for-john' of ↵John W. Linville2013-01-22
| | |\ \ | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
| | | * | iwlwifi: audit single frames from AGG queue in RSEmmanuel Grumbach2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rate scaling won't treat the information in a frame with IEEE80211_TX_CTL_AMPDU set if IEEE80211_TX_STAT_AMPDU is cleared. But all the frames coming from an AGG tx queue have IEEE80211_TX_CTL_AMPDU set, and IEEE80211_TX_STAT_AMPDU is set only if the frame was sent in an AMPDU. This means that all the data in frames in AGG tx queues that aren't sent as an AMPDU is thrown away. This is even more harmful when in bad link conditions, the frames are sent in an AMPDU and then finally sent as single frame. So a lot of failures weren't reported and the rate scaling got stuck in high rates leading to very poor connectivity. Fix that by clearing IEEE80211_TX_CTL_AMPDU when the frame isn't part of an AMPDU. This bug was introduced by 2eb81a40aa521035ff9c8c8309e482dff523f8c9 iwlwifi: don't clear CTL_AMPDU on frame status This fix basically reverts the aforementioned commit. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| | * | | ath9k: disable the tasklet before taking the PCU lockFelix Fietkau2013-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes a reported CPU soft lockup where the tasklet tries to acquire the lock and blocks while ath_prepare_reset (holding the lock) waits for it to complete. Cc: stable@vger.kernel.org Reported-by: Robert Shade <robert.shade@gmail.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k: remove sc->rx.rxbuflock to fix a deadlockFelix Fietkau2013-01-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit "ath9k: fix rx flush handling" added a deadlock that happens because ath_rx_tasklet is called in a section that has already taken the rx buffer lock. It seems that the only purpose of the rxbuflock was a band-aid fix to the reset vs rx tasklet race, which has been properly fixed in the commit "ath9k: add a better fix for the rx tasklet vs rx flush race". Now that the fix is in, we can safely remove the lock to avoid such issues. Cc: stable@vger.kernel.org Reported-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | brcmsmac: increase timer reference count for new timers onlyPiotr Haber2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On hardware reintialization reference count of already existing timers would be increased again. This leads to problems on module unloading. Cc: stable@vger.kernel.org Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Piotr Haber <phaber@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k: fix rx flush handlingFelix Fietkau2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now the rx flush is not doing anything useful on AR9003+, as it only works if the buffers in the rx FIFO have not been purged yet, as is done by ath_stoprecv. To fix this, always call ath_flushrecv from within ath_stoprecv before the FIFO is emptied, but still after the hw receive path has been stopped. This ensures that frames received (and ACKed by the hardware) shortly before a reset will be seen by the software, which should improve A-MPDU session stability. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k: add a better fix for the rx tasklet vs rx flush raceFelix Fietkau2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that the rx tasklet is no longer running when entering the reset path. Also remove the distinction between flush and no-flush frame processing. If a frame has been received and ACKed by the hardware, the stack needs to see it, so that the BA receive window does not go out of sync. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k: remove the WARN_ON that triggers if generating a beacon failsFelix Fietkau2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During teardown, mac80211 will not return a new beacon. This is normal and handled properly in the driver, so there's no need to spam the user with a kernel warning here. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k: fix double-free bug on beacon generate failureFelix Fietkau2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the next beacon is sent, the ath_buf from the previous run is reused. If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet the skb is freed, leading to a double-free on the next beacon tx attempt, resulting in a system crash. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k: do not link receive buffers during flushFelix Fietkau2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On AR9300 the rx FIFO needs to be empty during reset to ensure that no further DMA activity is generated, otherwise it might lead to memory corruption issues. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | ath9k_htc: Fix memory leakSujith Manoharan2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SKBs that are allocated in the HTC layer do not have callbacks registered and hence ended up not being freed, Fix this by freeing them properly in the TX completion routine. Cc: <stable@vger.kernel.org> Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | mwifiex: correct config_bands handling for ibss networkAmitkumar Karwar2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BAND_G is implicit when BAND_GN is present. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | mwifiex: update config_bands during infra associationAmitkumar Karwar2013-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently "adapter->config_bands" is updated during infra association only if channel is provided by user in "iw connect" command. config_bands is used while preparing association request to calculate supported rates by intersecting our rates with the rates advertised by AP. There is corner case in which we include zero rates in supported rates TLV based on previous IBSS network history, which leads to association failure. This patch fixes the problem by correctly updating config_bands. Cc: "3.7.y" <stable@vger.kernel.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | | Bluetooth: Check if the hci connection exists in SCO shutdownGustavo Padovan2013-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Checking only for sco_conn seems to not be enough and lead to NULL dereferences in the code, check for hcon instead. <1>[11340.226404] BUG: unable to handle kernel NULL pointer dereference at 0000000 8 <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0 <4>[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX: 00000000 <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c <0>[11340.226674] Stack: <4>[11340.226682] c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00 00000000 e0fdff5c <4>[11340.226718] c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852 d7813800 62262f10 <4>[11340.226752] e0fdff70 c1753c00 00000000 00000001 0000000d e0fdffac c175425c 00000041 <0>[11340.226793] Call Trace: <4>[11340.226813] [<c184db87>] ? sco_sock_clear_timer+0x27/0x60 <4>[11340.226831] [<c1251028>] ? local_bh_enable+0x68/0xd0 <4>[11340.226846] [<c1754aef>] ? lock_sock_nested+0x4f/0x60 <4>[11340.226862] [<c184f587>] sco_sock_shutdown+0x67/0xb0 <4>[11340.226879] [<c1751852>] ? sockfd_lookup_light+0x22/0x80 <4>[11340.226897] [<c1753c00>] sys_shutdown+0x30/0x60 <4>[11340.226912] [<c175425c>] sys_socketcall+0x1dc/0x2a0 <4>[11340.226929] [<c149ba78>] ? trace_hardirqs_on_thunk+0xc/0x10 <4>[11340.226944] [<c18860f1>] syscall_call+0x7/0xb <4>[11340.226960] [<c1880000>] ? restore_cur+0x5e/0xd7 <0>[11340.226969] Code: <f0> ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74 2f b8 0a 00 00 Reported-by: Chuansheng Liu <chuansheng.liu@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Fix authentication if acl data comes before remote feature evtJaganath Kanakkassery2013-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If remote device sends l2cap info request before read_remote_ext_feature completes then mgmt_connected will be sent in hci_acldata_packet() and remote name request wont be sent and eventually authentication wont happen Hcidump log of the issue < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr BC:85:1F:74:7F:29 ptype 0xcc18 rswitch 0x01 clkoffset 0x4bf7 (valid) Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 12 bdaddr BC:85:1F:74:7F:29 type ACL encrypt 0x00 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 12 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 > HCI Event: Max Slots Change (0x1b) plen 3 handle 12 slots 5 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 handle 12 page 1 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 > ACL data: handle 12 flags 0x02 dlen 10 L2CAP(s): Info req: type 2 < ACL data: handle 12 flags 0x00 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x00b8 Enhanced Retransmission mode Streaming mode FCS Option Fixed Channels > HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 12 page 1 max 1 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > ACL data: handle 12 flags 0x02 dlen 10 L2CAP(s): Info req: type 3 < ACL data: handle 12 flags 0x00 dlen 20 L2CAP(s): Info rsp: type 3 result 0 Fixed channel list 0x00000002 L2CAP Signalling Channel > HCI Event: Number of Completed Packets (0x13) plen 5 handle 12 packets 2 This patch moves sending mgmt_connected from hci_acldata_packet() to l2cap_connect_req() since this code is to handle the scenario remote device sends l2cap connect req too fast Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth device 04ca:3008 should use ath3kSergio Cambra2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Output of /sys/kernel/debug/usb/devices T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3008 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Sergio Cambra <sergio@programatica.es> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()Anderson Lizardo2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The length parameter should be sizeof(req->name) - 1 because there is no guarantee that string provided by userspace will contain the trailing '\0'. Can be easily reproduced by manually setting req->name to 128 non-zero bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on input subsystem: $ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af ("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys" field in struct hid_device due to overflow.) Cc: stable@vger.kernel.org Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Add support for Foxconn / Hon Hai [0489:e056]AceLan Kao2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the AR9462 chip T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e056 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Add support for Foxconn / Hon Hai [0489:e04e]AceLan Kao2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the AR9462 chip T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e04e Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.Daniel Schaal2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T: Bus=02 Lev=02 Prnt=02 Port=06 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3006 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Daniel Schaal <farbing@web.de> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Add support for IMC Networks [13d3:3393]AceLan Kao2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the AR9462 chip T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3393 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| | * | | Bluetooth: Fix sending HCI commands after resetSzymon Janc2013-01-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After sending reset command wait for its command complete event before sending next command. Some chips sends CC event for command received before reset if reset was send before chip replied with CC. This is also required by specification that host shall not send additional HCI commands before receiving CC for reset. < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612 > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850 Write Extended Inquiry Response (0x03|0x0052) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079 > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864 Reset (0x03|0x0003) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062 > HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835 Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Cc: stable@vger.kernel.org Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | | | ath9k_hw: remove a useless WARN_ONFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &ah->curchan->ani can never be NULL Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | ath9k_hw: reduce struct ar5416AniState sizeFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is kept per-channel, so removing unnecessary (or constant) fields from it can save quite a bit of memory. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | ath9k_hw: remove ath9k_hw_ani_setup and its variablesFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They are no longer needed for ANI functionality Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | ath9k_hw: make the initval parameter to ath9k_hw_write_array constFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | ath9k: use ath_tx_process_buffer instead of open-coding similar codeFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | ath9k: clean up processing of pending tx frames on resetFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dropping packets from aggregation sessions is usually not a good idea, as it might upset the synchronization of the BlockAck receive window of the remote node. The use of the retry_tx parameter to reset/tx-drain functions also seemed a bit arbitrary. This patch removes this parameter altogether and ensures that pending tx frames are not dropped for no good reason. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | ath9k: stop rx after txFelix Fietkau2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Completing frame transmission can fail if the rx engine is stopped prematurely, as the hw might be waiting for an ACK from the other side. Shutting down tx before rx might make the DMA shutdown more reliable. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | net: wireless/rtlwifi: fix uninitialized variable issueCong Ding2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of variable packet_beacon might be uninitialized in the three files. Signed-off-by: Cong Ding <dinggnu@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | iwlegacy: don't return zero on failure paths in il4965_pci_probe()Alexey Khoroshilov2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If hardware is not ready, il4965_pci_probe() breaks off initialization, deallocates all resources, but returns zero. The patch adds -EIO as return value in this case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | mwl8k: don't return zero on failure paths in mwl8k_probe[_hw]()Alexey Khoroshilov2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If pci_iomap() fails in mwl8k_probe(), it breaks off initialization, deallocates all resources, but returns zero. There is a similar issue when priv->rxd_ops is NULL in mwl8k_probe_hw(). The patch adds proper error code return values. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | mwifiex: correction in status codes used for association failureAmitkumar Karwar2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When AP responds with appropriate status code, we forward that code correctly to cfg80211. But sometimes when there is no response from AP, our firmware uses proprietary status codes. We will map authentication timeout to WLAN_STATUS_AUTH_TIMEOUT and other proprietary codes to WLAN_STATUS_UNSPECIFIED_FAILURE. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | rt2x00: Improve TX status handling for BlockAckReq framesHelmut Schaa2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since rt2800 hardware isn't capable of reporting the TX status of BlockAckReq frames implement the TX status handling of BARs in rt2x00lib. We keep track of all BARs that are send out and try to match incoming BAs to the appropriate BARs. This allows us to report a more or less accurate TX status for BAR frames which in turn improves BA session stability. This is loosley based on Christian Lamparter's patch for carl9170 "carl9170: fix HT peer BA session corruption". We have to walk the list of pending BARs for every rx'red BA even though most BAs don't belong to any of these BARs as they are just acknowledging an AMPDU. To keep that overhead low use RCU which allows us to walk the list of pending BARs without the need to acquire a lock. This however requires us to _copy_ relevant information from the BAR (RA, TA, control field, start sequence number) into our BAR list entry. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Tested-by: Andreas Hartmann <andihartmann@01019freenet.de> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | prism54: bug in getting auth typeDan Carpenter2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a missing break statement so SHARED_KEY authentication doesn't work. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | b43: N-PHY: fix gain in b43_nphy_get_gain_ctl_workaround_ent()Dan Carpenter2013-01-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were no break statements in this switch statement so everything used the default settings. Per Walter Harms's suggestion, I've replaced the switch statement and done a little cleanup. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-10-14 06:23:28 -0400