- 06 Dec, 2012 5 commits
-
-
Helmut Schaa authored
Otherwise rt2500* triggers a warning in cfg80211, from net/wireless/core.c: /* Combinations with just one interface aren't real */ if (WARN_ON(c->max_interfaces < 2)) This was introduced in commit 55d2e9da: rt2x00: Replace open coded interface checking with interface combinations. Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Cc: stable@vger.kernel.org [3.7+] Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Dan Carpenter reported that smatch detected a potential problem with the code [1]: drivers/net/wireless/ath/carl9170/tx.c:1488 carl9170_op_tx() error: we previously assumed 'sta' could be null (see line 1482) drivers/net/wireless/ath/carl9170/tx.c 1482 if (sta) { ^^^^^ New check. [...] 1485 } 1487 if (info->flags & IEEE80211_TX_CTL_AMPDU) { 1488 run = carl9170_tx_ampdu_queue(ar, sta, skb); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Old dereference of "sta" inside the call to carl9170_tx_ampdu_queue(). A range of solutions have been discussed in [2] and we agreed on the following: " > we might as well add a comment to carl9170_tx_ampdu_queue > and explain the situation [in a way that's obvious to a > human reader]. This way we can save the "if"... which is > a small win since carl9170_op_tx is sort of a hot-path. Putting a comment there is fine. Without the comment it's easy for a human reader to get confused why the check is there. So long as humans can read the code, that's all that matters." [1] <http://www.spinics.net/lists/linux-wireless/msg94526.html> [2] <http://www.spinics.net/lists/linux-kernel-janitors/msg14953.html> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
spinlock_t should always be used. LD drivers/net/wireless/brcm80211/built-in.o CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o CHECK drivers/net/wireless/brcm80211/brcmfmac/fwil.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/fwil.o CHECK drivers/net/wireless/brcm80211/brcmfmac/fweh.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/fweh.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_common.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o CHECK drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.o CHECK drivers/net/wireless/brcm80211/brcmfmac/usb.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/usb.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.o LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o LD drivers/net/wireless/brcm80211/brcmsmac/built-in.o CHECK drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1311:6: warning: context imbalance in 'brcms_down' - unexpected unlock drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1598:6: warning: context imbalance in 'brcms_rfkill_set_hw_state' - unexpected unlock CC [M] drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o CHECK drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o CHECK drivers/net/wireless/brcm80211/brcmsmac/ampdu.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/ampdu.o CHECK drivers/net/wireless/brcm80211/brcmsmac/antsel.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/antsel.o CHECK drivers/net/wireless/brcm80211/brcmsmac/channel.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/channel.o CHECK drivers/net/wireless/brcm80211/brcmsmac/main.c drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:36: warning: Initializer entry defined twice drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:43: also defined here CC [M] drivers/net/wireless/brcm80211/brcmsmac/main.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o CHECK drivers/net/wireless/brcm80211/brcmsmac/pmu.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/pmu.o CHECK drivers/net/wireless/brcm80211/brcmsmac/rate.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/rate.o CHECK drivers/net/wireless/brcm80211/brcmsmac/stf.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/stf.o CHECK drivers/net/wireless/brcm80211/brcmsmac/aiutils.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/aiutils.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c:3313:46: warning: cast truncates bits from constant value (ffff7fff becomes 7fff) CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:17688:47: warning: cast truncates bits from constant value (ffff7fff becomes 7fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:18187:53: warning: cast truncates bits from constant value (ffff3fff becomes 3fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:21160:36: warning: cast truncates bits from constant value (ffff3fff becomes 3fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:23321:35: warning: cast truncates bits from constant value (ffff7fff becomes 7fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:28343:44: warning: cast truncates bits from constant value (ffff1fff becomes 1fff) CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.o CHECK drivers/net/wireless/brcm80211/brcmsmac/dma.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/dma.o CHECK drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.o CHECK drivers/net/wireless/brcm80211/brcmsmac/debug.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/debug.o LD [M] drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.o LD drivers/net/wireless/brcm80211/brcmutil/built-in.o CHECK drivers/net/wireless/brcm80211/brcmutil/utils.c CC [M] drivers/net/wireless/brcm80211/brcmutil/utils.o LD [M] drivers/net/wireless/brcm80211/brcmutil/brcmutil.o Building modules, stage 2. MODPOST 3 modules CC drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.mod.o LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko CC drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.mod.o LD [M] drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko CC drivers/net/wireless/brcm80211/brcmutil/brcmutil.mod.o LD [M] drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko Cc: Brett Rudley <brudley@broadcom.com> Cc: Roland Vossen <rvossen@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com> Cc: Kan Yan <kanyan@broadcom.com> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list@broadcom.com Reported-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-nextJohn W. Linville authored
Conflicts: drivers/net/wireless/mwifiex/sta_ioctl.c net/mac80211/scan.c
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0John W. Linville authored
This is an NFC LLCP fix for 3.7 and contains only one patch. It fixes a potential crash when receiving an LLCP HDLC frame acking a frame that is not the last sent one. In that case we may dereference an already freed pointer.
-
- 03 Dec, 2012 23 commits
-
-
Florian Fainelli authored
This patch removes a left over debugging print present in the pci shutdown callback, since this callback does not do anything useful, get rid of it entirely. Signed-off-by: Florian Fainelli <ffainelli@freebox.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
On the RF3290,RF5360,RF5370,RF5372,RF5390,RF5392 radio frontends, the VCO calibration can be controlled via the RFCSR3 register. The current code uses the RFCSR30_RF_CALIBRATION constant to enable the calibration, however that belongs to the RFCSR30 register. Although the values of the constant is correct, but using that for another register is confusing. Add a new definition for the VCO calibration enable bit of the RFCSR3 register and use that in the relevant places in order to avoid confusions. The patch contains no functional changes. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
On A-MPDU frames, the hardware only reports valid signal strength data for the last subframe. This patch fixes it by flagging everything but the last subframe in an A-MPDU to tell mac80211 to ignore the signal strength entirely. Otherwise the empty value (= 0 dbm) will distort the average quite badly. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
The patch contains no functional changes. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
The patch contains no functional changes. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Carpenter authored
"entries" is unsigned here, so it is never less than zero. In theory, len could be less than offset so I have added a check for that. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
-
Gustavo Padovan authored
This reverts commit 269c4845. The commit was causing dead locks and NULL dereferences in the sco code: [28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7] [28084.104021] Modules linked in: btusb bluetooth <snip [last unloaded: bluetooth] ... [28084.104021] [<c160246d>] _raw_spin_lock+0xd/0x10 [28084.104021] [<f920e708>] sco_conn_del+0x58/0x1b0 [bluetooth] [28084.104021] [<f920f1a9>] sco_connect_cfm+0xb9/0x2b0 [bluetooth] [28084.104021] [<f91ef289>] hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth] [28084.104021] [<f91f1a8d>] hci_event_packet+0x74d/0x2b40 [bluetooth] [28084.104021] [<c1501abd>] ? __kfree_skb+0x3d/0x90 [28084.104021] [<c1501b46>] ? kfree_skb+0x36/0x90 [28084.104021] [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] [28084.104021] [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] Cc: stable@vger.kernel.org Reported-by: Chan-yeol Park <chanyeol.park@gmail.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Andrei Emeltchenko authored
Make code more readable by changing CONF_NO_FCS_RECV which is read as "No L2CAP FCS option received" to CONF_RECV_NO_FCS which means "Received L2CAP option NO_FCS". This flag really means that we have received L2CAP FRAME CHECK SEQUENCE (FCS) OPTION with value "No FCS". Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Andrei Emeltchenko authored
Process L2CAP Config rsp Pending with FCS Option 0x00 (No FCS) which is sent by Motorola Windows 7 Bluetooth stack. The trace is shown below (all other options are skipped). ... < ACL data: handle 1 flags 0x00 dlen 48 L2CAP(s): Config req: dcid 0x0043 flags 0x00 clen 36 ... FCS Option 0x00 (No FCS) > ACL data: handle 1 flags 0x02 dlen 48 L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 36 ... FCS Option 0x01 (CRC16 Check) < ACL data: handle 1 flags 0x00 dlen 47 L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 4 clen 33 Pending ... > ACL data: handle 1 flags 0x02 dlen 50 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 4 clen 36 Pending ... FCS Option 0x00 (No FCS) < ACL data: handle 1 flags 0x00 dlen 14 L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 0 clen 0 Success > ACL data: handle 1 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0 Success ... Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Andrei Emeltchenko authored
If L2CAP_FEAT_FCS is not supported we sould miss EWS option configuration because of break. Make code more readable by combining FCS configuration in the single block. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Andrei Emeltchenko authored
Before starting quering remote AMP controllers make sure that there is local active AMP controller. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Andrei Emeltchenko authored
After getting HCIDEVDOWN controller did not mark itself as 0x00 which means: "The Controller radio is available but is currently physically powered down". The result was even if the hdev was down we return in controller list value 0x01 "status 0x01 (Bluetooth only)". Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Andrei Emeltchenko authored
l2cap_send_disconn_req takes 3 parameters of which conn might be derived from chan. Make this conversion inside l2cap_send_disconn_req. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Gustavo Padovan authored
Some comparisons needs to double negation(!!) in order to make the value of the field boolean. Add it to the macro makes the code more readable. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Frédéric Dalleau authored
In order to authenticate and configure an incoming SCO connection, the BT_DEFER_SETUP option was added. This option is intended to defer reply to Connect Request on SCO sockets. When a connection is requested, the listening socket is unblocked but the effective connection setup happens only on first recv. Any send between accept and recv fails with -ENOTCONN. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Frédéric Dalleau authored
This option will set the BT_SK_DEFER_SETUP bit in socket flags. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Gustavo Padovan authored
We need to cancel the hci_power_on work in order to avoid it run when we try to free the hdev. [ 1434.201149] ------------[ cut here ]------------ [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci _power_on+0x0/0x90 [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-next- 20121112-sasha-00018-g2f4ce0e #127 [ 1434.210760] Call Trace: [ 1434.210760] [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0 [ 1434.210760] [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0 [ 1434.210760] [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50 [ 1434.210760] [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0 [ 1434.210760] [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310 [ 1434.210760] [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0 [ 1434.210760] [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230 [ 1434.210760] [<ffffffff83785db0>] ? bt_host_release+0x10/0x20 [ 1434.210760] [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20 [ 1434.210760] [<ffffffff8125eee7>] kfree+0x227/0x330 [ 1434.210760] [<ffffffff83785db0>] bt_host_release+0x10/0x20 [ 1434.210760] [<ffffffff81e539e5>] device_release+0x65/0xc0 [ 1434.210760] [<ffffffff819d3975>] kobject_cleanup+0x145/0x190 [ 1434.210760] [<ffffffff819d39cd>] kobject_release+0xd/0x10 [ 1434.210760] [<ffffffff819d33cc>] kobject_put+0x4c/0x60 [ 1434.210760] [<ffffffff81e548b2>] put_device+0x12/0x20 [ 1434.210760] [<ffffffff8376a334>] hci_free_dev+0x24/0x30 [ 1434.210760] [<ffffffff82fd8fe1>] vhci_release+0x31/0x60 [ 1434.210760] [<ffffffff8127be12>] __fput+0x122/0x250 [ 1434.210760] [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0 [ 1434.210760] [<ffffffff8127bf49>] ____fput+0x9/0x10 [ 1434.210760] [<ffffffff81133402>] task_work_run+0xb2/0xf0 [ 1434.210760] [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0 [ 1434.210760] [<ffffffff83bfb0ea>] int_signal+0x12/0x17 [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]--- Cc: stable@vger.kernel.org Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Gustavo Padovan authored
This patch fixes the following report, it happens when accepting rfcomm connections: [ 228.165378] ============================================= [ 228.165378] [ INFO: possible recursive locking detected ] [ 228.165378] 3.7.0-rc1-00536-gc1d5dc4a #120 Tainted: G W [ 228.165378] --------------------------------------------- [ 228.165378] bluetoothd/1341 is trying to acquire lock: [ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth] [ 228.165378] [ 228.165378] but task is already holding lock: [ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm] [ 228.165378] [ 228.165378] other info that might help us debug this: [ 228.165378] Possible unsafe locking scenario: [ 228.165378] [ 228.165378] CPU0 [ 228.165378] ---- [ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM); [ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM); [ 228.165378] [ 228.165378] *** DEADLOCK *** [ 228.165378] [ 228.165378] May be due to missing lock nesting notation Cc: stable@vger.kernel.org Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Marco Porsch authored
Fix an error on mesh join when no channel has been explicitly set beforehand. Also remove a double semicolon. Signed-off-by: Marco Porsch <marco.porsch@etit.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Simon Wunderlich authored
If channel contexts are enabled, the CSA should not be processed further. A return is missing here. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Simon Wunderlich authored
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 30 Nov, 2012 12 commits
-
-
Seth Forshee authored
There's a debug message to warn if this function is passed a NULL pointer, but in order to print the message we have to dereference the pointer. Obviously this isn't a good idea, so remove the message. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Masanari Iida authored
Correct spelling typo in wireless/mwifiex driver. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
rtlwifi only provides pm callbacks for functions covered by pm sleep and they are also just called if CONFIG_PM_SLEEP is set. Only add functions rtl_pci_suspend and rtl_pci_resume if CONFIG_PM_SLEEP is set and use SIMPLE_DEV_PM_OPS instead of manually filling struct dev_pm_ops. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
p54pci does not provide any runtime pm callbacks, so support for PM_RUNTIME is not needed and we could go to PM_SLEEP. This also makes it possible to use SIMPLE_DEV_PM_OPS instead of manually filling struct dev_pm_ops. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
ath9k does not provide any runtime pm callbacks, so support for PM_RUNTIME is not needed and we could go to PM_SLEEP. This also makes it possible to use SIMPLE_DEV_PM_OPS instead of manually filling struct dev_pm_ops. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Daniel Stamer authored
This patch fixes almost all coding issues in the rtl8192se driver. Only exception is putting trailing */ on separate lines. Signed-off-by: Daniel Stamer <daniel@stamer.info> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Using bss->information_elements and treating bss->len_beacon_ies as its size is wrong, the real size is len_information_elements. Found while I was reviewing the use of this cfg80211 API (as it is actually potentially broken due to races.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
see header. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
Parsing vndrs ie was not taking len of tlv itself in account. Setting mgmt ie was missing check for length indicating non configured ie and wrongly checking available length. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
The mode should be stored and used per virtual interface. Remove the mode from device global structure and rework the code to use the mode from brcmf_cfg80211_vif. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
This attribute indicates successful IBSS or AP connection has been established. However, this no longer works for virtual interfaces. As it turns out this attribute is identical to the CONNECTED bit in struct brcmf_cfg80211_vif::sme_state. This patch removes the attribute and rework some functions relying on it. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Piotr Haber authored
Add support for 4313 iPA variant. It is a variant of already supported 4313 ePA and needs some PHY changes to work properly. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@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>
-