If the expected throughput is queried before rate control has been
initialized, the minstrel op for it will crash while trying to access
the rate table.
Check for WLAN_STA_RATE_CONTROL before attempting to use the rate
control op.
Reported-by: Jean-Pierre Tosoni <jp.tosoni@acksys.fr>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In AP mode, configure the fw to pass beacons from
foreign APs, in order to be able to set the ht
protection IE properly.

Add the same filters in case of GO (which didn't have
any configured filter_flags, probably by mistake)
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

tsc can be NULL (mac80211 currently always passes NULL),
resulting in NULL-dereference. check before copying it.

Cc: stable@vger.kernel.org
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Function rt2800usb_autorun_detect() passes the address of a variable
allocated onto the stack to be used for DMA by the USB layer. This has
been caught by my debugging-enabled kernel.

This patch change things in order to allocate that variable via
kmalloc, and it adjusts things to handle the kmalloc failure case,
propagating the error.

[ 7363.238852] ------------[ cut here ]------------
[ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0()
[ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4]
[ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib]
[ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G           O  3.16.0-rc3-wl+ #31
[ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
[ 7363.297511]  0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758
[ 7363.305062]  ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0
[ 7363.312622]  ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8
[ 7363.320161] Call Trace:
[ 7363.322661]  [<ffffffff8175dcad>] dump_stack+0x4d/0x6f
[ 7363.327847]  [<ffffffff8106d372>] warn_slowpath_common+0x82/0xb0
[ 7363.333893]  [<ffffffff8106d3e7>] warn_slowpath_fmt+0x47/0x50
[ 7363.339686]  [<ffffffff813a93b4>] check_for_stack+0xa4/0xf0
[ 7363.345298]  [<ffffffff813a995c>] debug_dma_map_page+0x10c/0x150
[ 7363.351367]  [<ffffffff81521bd9>] usb_hcd_map_urb_for_dma+0x229/0x720
[ 7363.357890]  [<ffffffff8152256d>] usb_hcd_submit_urb+0x2fd/0x930
[ 7363.363929]  [<ffffffff810eac31>] ? irq_work_queue+0x71/0xd0
[ 7363.369617]  [<ffffffff810ab5a7>] ? wake_up_klogd+0x37/0x50
[ 7363.375219]  [<ffffffff810ab7a5>] ? console_unlock+0x1e5/0x420
[ 7363.381081]  [<ffffffff810abc25>] ? vprintk_emit+0x245/0x530
[ 7363.386773]  [<ffffffff81523d3c>] usb_submit_urb+0x30c/0x580
[ 7363.392462]  [<ffffffff81524295>] usb_start_wait_urb+0x65/0xf0
[ 7363.398325]  [<ffffffff815243ed>] usb_control_msg+0xcd/0x110
[ 7363.404014]  [<ffffffffa005514d>] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb]
[ 7363.411544]  [<ffffffffa0074292>] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb]
[ 7363.418986]  [<ffffffffa0074aa1>] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb]
[ 7363.426168]  [<ffffffffa0063ffd>] rt2800_probe_hw+0x11d/0xf90 [rt2800lib]
[ 7363.432989]  [<ffffffffa0074b7d>] rt2800usb_probe_hw+0xd/0x50 [rt2800usb]
[ 7363.439808]  [<ffffffffa00453d8>] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib]
[ 7363.446992]  [<ffffffffa00bfa48>] ? ieee80211_led_names+0xb8/0x100 [mac80211]
[ 7363.454156]  [<ffffffffa0056116>] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb]
[ 7363.460971]  [<ffffffffa0074250>] rt2800usb_probe+0x10/0x20 [rt2800usb]
[ 7363.467616]  [<ffffffff8152799e>] usb_probe_interface+0xce/0x1c0
[ 7363.473651]  [<ffffffff81480c20>] really_probe+0x70/0x240
[ 7363.479079]  [<ffffffff81480f01>] __driver_attach+0xa1/0xb0
[ 7363.484682]  [<ffffffff81480e60>] ? __device_attach+0x70/0x70
[ 7363.490461]  [<ffffffff8147eef3>] bus_for_each_dev+0x63/0xa0
[ 7363.496146]  [<ffffffff814807c9>] driver_attach+0x19/0x20
[ 7363.501570]  [<ffffffff81480468>] bus_add_driver+0x178/0x220
[ 7363.507270]  [<ffffffff8148151b>] driver_register+0x5b/0xe0
[ 7363.512874]  [<ffffffff815271b0>] usb_register_driver+0xa0/0x170
[ 7363.518905]  [<ffffffffa007a000>] ? 0xffffffffa0079fff
[ 7363.524074]  [<ffffffffa007a01e>] rt2800usb_driver_init+0x1e/0x20 [rt2800usb]
[ 7363.531247]  [<ffffffff810002d4>] do_one_initcall+0x84/0x1b0
[ 7363.536932]  [<ffffffff8113aa60>] ? kfree+0xd0/0x110
[ 7363.541931]  [<ffffffff8112730a>] ? __vunmap+0xaa/0xf0
[ 7363.547538]  [<ffffffff810ca07e>] load_module+0x1aee/0x2040
[ 7363.553141]  [<ffffffff810c6f10>] ? store_uevent+0x50/0x50
[ 7363.558676]  [<ffffffff810ca66e>] SyS_init_module+0x9e/0xc0
[ 7363.564285]  [<ffffffff81764012>] system_call_fastpath+0x16/0x1b
[ 7363.570338] ---[ end trace 01ef5f822bea9882 ]---
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This reverts commit 277d916f as it was
at least breaking iwlwifi by setting the IEEE80211_TX_CTL_NO_PS_BUFFER
flag in all kinds of interface modes, not only for AP mode where it is
appropriate.

To avoid reintroducing the original problem, explicitly check for probe
request frames in the multicast buffering code.

Cc: stable@vger.kernel.org
Fixes: 277d916f ("mac80211: move "bufferable MMPDU" check to fix AP mode scan")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

There are few places at the begining of Tx/Rx paths where
tx_info/rx_info is not correctly initialized. This patch
takes care of it.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Firmware folks seem say that this flag can make trouble.
Drop it. The advantage of CTS to self is that it slightly
reduces the cost of the protection, but make the protection
less reliable.

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

We should always prefer to use full RTS protection. Using
CTS to self gives a meaningless improvement, but this flow
is much harder for the firmware which is likely to have
issues with it.

CC: <stable@vger.kernel.org>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The function brcmf_usb_dlneeded() queries the device to obtain the chip
id and revision. So assigning these in bus interface before the call
resulted in chip id and revision being zero. This was introduced by:

   commit 5b8045d4
   Author: Arend van Spriel <arend@broadcom.com>
   Date:   Tue May 27 12:56:23 2014 +0200

       brcmfmac: use asynchronous firmware request in USB
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

https://bugzilla.kernel.org/show_bug.cgi?id=70191
https://bugzilla.kernel.org/show_bug.cgi?id=77581

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Cc: <stable@vger.kernel.org>
Reported-by: Andrew Wiley <wiley.andrew.j@gmail.com>
Reported-by: Linus Gasser <list@markas-al-nour.org>
Reported-by: Michael Hirsch <hirsch@teufel.de>
Tested-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Current code did not allow sending the broadcast filtering command
for P2P Client interfaces. However, this was not enough, since once
broadcast filtering command was issued over the station interface
after the P2P Client connected, the command also attached the filters
to the P2P Client MAC which is not allowed (FW ASSERT 1063).

Fix this skipping P2P Client interfaces when constructing the broadcast
filtering command
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: ArikX Nemtsov <arik@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This reverts commit dc9a1929.

3610 cards don't support UAPSD.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Add one more 7265 series HW ID.
Edit one existing 7265 series HW ID.

CC: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The non-split wiphy state shouldn't be increased in size
so move the new set_qos_map command into the split if
statement.

Cc: stable@vger.kernel.org (3.14+)
Fixes: fa9ffc74 ("cfg80211: Add support for QoS mapping")
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The current sched scan channel configuration code
configures all the supported channels for scanning.

However, this can result in SYSASSERT in some cases,
when the configured channel is disabled.

Instead, configure only the channels given in the
req struct, and set the channel_count field appropriately.

While on it, change the code to use channel->hw_value
instead of recalculating the channel number.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

When detecting a non-link packet, h5_reset_rx() frees the Rx skb.
Not returning after that will cause the upcoming h5_rx_payload()
call to dereference a now NULL Rx skb and trigger a kernel oops.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org

MAX_JIFFY_OFFSET has no meaning when calculating the
elapsed jiffies, as jiffies run out until ULONG_MAX.

This miscalculation results in erroneous values
in case of a wrap-around.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This reverts commit 8eca1fb6.

Felix notes that this broke regulatory, leaving channel 12 open for AP
operation in the US regulatory domain where it isn't permitted.

Link: http://mid.gmane.org/53A6C0FF.9090104@openwrt.orgReported-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

After skb allocation and call to ieee80211_wep_encrypt in ieee80211_send_auth
the flow fails with a warning in ieee80211_wep_add_iv on verification of
available head/tailroom needed for WEP_IV and WEP_ICV.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When pairing fails hci_conn refcnt drops below zero. This cause that
ACL link is not disconnected when disconnect timeout fires.

Probably this is because l2cap_conn_del calls l2cap_chan_del for each
channel, and inside l2cap_chan_del conn is dropped. After that loop
hci_chan_del is called which also drops conn.

Anyway, as it is desrcibed in hci_core.h, it is known that refcnt
drops below 0 sometimes and it should be fine. If so, let disconnect
link when hci_conn_timeout fires and refcnt is 0 or below. This patch
does it.

This affects PTS test SM_TC_JW_BV_05_C

Logs from scenario:

[69713.706227] [6515] pair_device:
[69713.706230] [6515] hci_conn_add: hci0 dst 00:1b:dc:06:06:22
[69713.706233] [6515] hci_dev_hold: hci0 orig refcnt 8
[69713.706235] [6515] hci_conn_init_sysfs: conn ffff88021f65a000
[69713.706239] [6515] hci_req_add_ev: hci0 opcode 0x200d plen 25
[69713.706242] [6515] hci_prepare_cmd: skb len 28
[69713.706243] [6515] hci_req_run: length 1
[69713.706248] [6515] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 0
[69713.706251] [6515] hci_dev_put: hci0 orig refcnt 9
[69713.706281] [8909] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1
[69713.706288] [8909] hci_send_frame: hci0 type 1 len 28
[69713.706290] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 28
[69713.706316] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.706382] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.711664] [8909] hci_rx_work: hci0
[69713.711668] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 6
[69713.711680] [8909] hci_rx_work: hci0 Event packet
[69713.711683] [8909] hci_cs_le_create_conn: hci0 status 0x00
[69713.711685] [8909] hci_sent_cmd_data: hci0 opcode 0x200d
[69713.711688] [8909] hci_req_cmd_complete: opcode 0x200d status 0x00
[69713.711690] [8909] hci_sent_cmd_data: hci0 opcode 0x200d
[69713.711695] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.711744] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.818875] [8909] hci_rx_work: hci0
[69713.818889] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 21
[69713.818913] [8909] hci_rx_work: hci0 Event packet
[69713.818917] [8909] hci_le_conn_complete_evt: hci0 status 0x00
[69713.818922] [8909] hci_send_to_control: len 19
[69713.818927] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.818938] [8909] hci_conn_add_sysfs: conn ffff88021f65a000
[69713.818975] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
[69713.818981] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
...
[69713.819021] [8909] hci_dev_hold: hci0 orig refcnt 10
[69713.819025] [8909] l2cap_connect_cfm: hcon ffff88021f65a000 bdaddr 00:1b:dc:06:06:22 status 0
[69713.819028] [8909] hci_chan_create: hci0 hcon ffff88021f65a000
[69713.819031] [8909] l2cap_conn_add: hcon ffff88021f65a000 conn ffff880221005c00 hchan ffff88020d60b1c0
[69713.819034] [8909] l2cap_conn_ready: conn ffff880221005c00
[69713.819036] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.819037] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x02
[69713.819039] [8909] smp_chan_create:
[69713.819041] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 1
[69713.819043] [8909] smp_send_cmd: code 0x01
[69713.819045] [8909] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000
[69713.819046] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800
[69713.819049] [8909] hci_queue_acl: hci0 nonfrag skb ffff88005157c100 len 15
[69713.819055] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800
[69713.819057] [8909] l2cap_le_conn_ready:
[69713.819064] [8909] l2cap_chan_create: chan ffff88005ede2c00
[69713.819066] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 1
[69713.819069] [8909] l2cap_sock_init: sk ffff88005ede5800
[69713.819072] [8909] bt_accept_enqueue: parent ffff880160356000, sk ffff88005ede5800
[69713.819074] [8909] __l2cap_chan_add: conn ffff880221005c00, psm 0x00, dcid 0x0004
[69713.819076] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 2
[69713.819078] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 2
[69713.819080] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x01
[69713.819082] [8909] l2cap_sock_ready_cb: sk ffff88005ede5800, parent ffff880160356000
[69713.819086] [8909] le_pairing_complete_cb: status 0
[69713.819091] [8909] hci_tx_work: hci0 acl 10 sco 8 le 0
[69713.819093] [8909] hci_sched_acl: hci0
[69713.819094] [8909] hci_sched_sco: hci0
[69713.819096] [8909] hci_sched_esco: hci0
[69713.819098] [8909] hci_sched_le: hci0
[69713.819099] [8909] hci_chan_sent: hci0
[69713.819101] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 10
[69713.819104] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff88005157c100 len 15 priority 7
[69713.819106] [8909] hci_send_frame: hci0 type 2 len 15
[69713.819108] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 15
[69713.819119] [8909] hci_chan_sent: hci0
[69713.819121] [8909] hci_prio_recalculate: hci0
[69713.819123] [8909] process_pending_rx:
[69713.819226] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400
...
[69713.822022] [6450] l2cap_sock_accept: sk ffff880160356000 timeo 0
[69713.822024] [6450] bt_accept_dequeue: parent ffff880160356000
[69713.822026] [6450] bt_accept_unlink: sk ffff88005ede5800 state 1
[69713.822028] [6450] l2cap_sock_accept: new socket ffff88005ede5800
[69713.822368] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.822375] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.822383] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.822414] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
...
[69713.823255] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.823259] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.824322] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.824330] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.825029] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69713.825187] [6450] l2cap_sock_sendmsg: sock ffff8800941ab700, sk ffff88005ede5800
[69713.825189] [6450] bt_sock_wait_ready: sk ffff88005ede5800
[69713.825192] [6450] l2cap_create_basic_pdu: chan ffff88005ede2c00 len 3
[69713.825196] [6450] l2cap_do_send: chan ffff88005ede2c00, skb ffff880160b0b500 len 7 priority 0
[69713.825199] [6450] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000
[69713.825201] [6450] hci_queue_acl: hci0 nonfrag skb ffff880160b0b500 len 11
[69713.825210] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0
[69713.825213] [8909] hci_sched_acl: hci0
[69713.825214] [8909] hci_sched_sco: hci0
[69713.825216] [8909] hci_sched_esco: hci0
[69713.825217] [8909] hci_sched_le: hci0
[69713.825219] [8909] hci_chan_sent: hci0
[69713.825221] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 9
[69713.825223] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff880160b0b500 len 11 priority 0
[69713.825225] [8909] hci_send_frame: hci0 type 2 len 11
[69713.825227] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 11
[69713.825242] [8909] hci_chan_sent: hci0
[69713.825253] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.825253] [8909] hci_prio_recalculate: hci0
[69713.825292] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.825768] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69713.866902] [8909] hci_rx_work: hci0
[69713.866921] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 7
[69713.866928] [8909] hci_rx_work: hci0 Event packet
[69713.866931] [8909] hci_num_comp_pkts_evt: hci0 num_hndl 1
[69713.866937] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0
[69713.866939] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.866940] [8909] hci_sched_acl: hci0
...
[69713.866944] [8909] hci_sched_le: hci0
[69713.866953] [8909] hci_chan_sent: hci0
[69713.866997] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.867840] [28074] hci_rx_work: hci0
[69713.867844] [28074] hci_send_to_monitor: hdev ffff88021f0c7000 len 7
[69713.867850] [28074] hci_rx_work: hci0 Event packet
[69713.867853] [28074] hci_num_comp_pkts_evt: hci0 num_hndl 1
[69713.867857] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.867858] [28074] hci_tx_work: hci0 acl 10 sco 8 le 0
[69713.867860] [28074] hci_sched_acl: hci0
[69713.867861] [28074] hci_sched_sco: hci0
[69713.867862] [28074] hci_sched_esco: hci0
[69713.867863] [28074] hci_sched_le: hci0
[69713.867865] [28074] hci_chan_sent: hci0
[69713.867888] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145661] [8909] hci_rx_work: hci0
[69714.145666] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 10
[69714.145676] [8909] hci_rx_work: hci0 ACL data packet
[69714.145679] [8909] hci_acldata_packet: hci0 len 6 handle 0x002d flags 0x0002
[69714.145681] [8909] hci_conn_enter_active_mode: hcon ffff88021f65a000 mode 0
[69714.145683] [8909] l2cap_recv_acldata: conn ffff880221005c00 len 6 flags 0x2
[69714.145693] [8909] l2cap_recv_frame: len 2, cid 0x0006
[69714.145696] [8909] hci_send_to_control: len 14
[69714.145710] [8909] smp_chan_destroy:
[69714.145713] [8909] pairing_complete: status 3
[69714.145714] [8909] cmd_complete: sock ffff88010323ac00
[69714.145717] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 3
[69714.145719] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145720] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
[69714.145722] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
[69714.145724] [6450] bt_sock_poll: sock ffff8801db6b4f00, sk ffff880160351c00
...
[69714.145735] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
[69714.145737] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 2
[69714.145739] [8909] l2cap_conn_del: hcon ffff88021f65a000 conn ffff880221005c00, err 13
[69714.145740] [6450] bt_sock_poll: sock ffff8801db6b5400, sk ffff88021e775000
[69714.145743] [6450] bt_sock_poll: sock ffff8801db6b5e00, sk ffff880160356000
[69714.145744] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 3
[69714.145746] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
[69714.145748] [8909] l2cap_chan_del: chan ffff88005ede2c00, conn ffff880221005c00, err 13
[69714.145749] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 4
[69714.145751] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 1
[69714.145754] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
[69714.145756] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 3
[69714.145759] [8909] hci_chan_del: hci0 hcon ffff88021f65a000 chan ffff88020d60b1c0
[69714.145766] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145787] [6515] hci_sock_release: sock ffff88005e75a080 sk ffff88010323ac00
[69714.146002] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400
[69714.150795] [6450] l2cap_sock_release: sock ffff8800941ab700, sk ffff88005ede5800
[69714.150799] [6450] l2cap_sock_shutdown: sock ffff8800941ab700, sk ffff88005ede5800
[69714.150802] [6450] l2cap_chan_close: chan ffff88005ede2c00 state BT_CLOSED
[69714.150805] [6450] l2cap_sock_kill: sk ffff88005ede5800 state BT_CLOSED
[69714.150806] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 2
[69714.150808] [6450] l2cap_sock_destruct: sk ffff88005ede5800
[69714.150809] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 1
[69714.150811] [6450] l2cap_chan_destroy: chan ffff88005ede2c00
[69714.150970] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69714.151991] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 0
[69716.150339] [8909] hci_conn_timeout: hcon ffff88021f65a000 state BT_CONNECTED, refcnt -1
Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

If we need an MITM protected connection but the local and remote IO
capabilities cannot provide it we should reject the pairing attempt in
the appropriate way. This patch adds the missing checks for such a
situation to the smp_cmd_pairing_req() and smp_cmd_pairing_rsp()
functions.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

We'll need to do authentication method lookups from more than one place,
so refactor the lookup into its own function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

When we receive a pairing request or an internal request to start
pairing we shouldn't blindly overwrite the existing pending_sec_level
value as that may actually be higher than the new one. This patch fixes
the SMP code to only overwrite the value in case the new one is higher
than the old.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This reverts commit ca58e594.

For some unclear reason this patch tries to add suport for the
product ID 0xe005, but it ends up adding product ID 0x3005 to
all the tables. This is obviously wrong and causing multiple
issues.

The original patch seemed to be fine, but what ended up in 3.15
is not what the patch intended. The commit 0a3658cc is
already present and adds support for this hardware. This means
only revert of this broken commit is requird.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reported-by: Alexander Holler <holler@ahsoftware.de>
Cc: stable@vger.kernel.org # 3.15.x

As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5f, generally sane change) broke rfkill on rt2500pci
device. I considered that bug as some initalization issue, which
should be fixed on rt2500pci specific code. But after several
attempts (see bug report for details) we fail to find working solution.
Hence I decided to revert to old behaviour on rt2500pci to fix
regression.

Additionally patch also unregister rfkill on device remove instead
of ifconfig down, what was another issue introduced by bad commit.

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=73821

Fixes: e2bc7c5f ("rt2x00: Fix rfkill_polling register function.")
Cc: stable@vger.kernel.org
Bisected-by: Niels <nille0386@googlemail.com>
Reported-and-tested-by: Niels <nille0386@googlemail.com>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).

So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:

commit 3afc2167
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Mar 4 16:50:13 2014 +0200

    cfg80211/mac80211: ignore signal if the frame was heard on wrong channel
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) boots into a state that does
not actually require loading a firmware file. The vendors driver finds out
about this by checking a firmware state register, so this patch adds this here.

Finally, with this patch applied, my wifi dongle actually becomes
useful (scan + connect to wpa network works).
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) currently does not
load. One thing observed is that the vendors driver detects EFUSE mode
for this device, but rt2800usb does not. This is due to rt2800usb
lacking a check for the firmware mode present in the vendors driver,
that this patch adopts for rt2800usb.

With this patch applied, the 'RF chipset' detection does no longer fail.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

On USB we can not get atomically TKIP key. We have to disable support
for TKIP acceleration on USB hardware to avoid bug as showed bellow.

[  860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002
<snip>
[  860.827280] Call Trace:
[  860.827282]  [<ffffffff81682ea6>] dump_stack+0x4d/0x66
[  860.827284]  [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55
[  860.827285]  [<ffffffff81685bb3>] __schedule+0x733/0x7b0
[  860.827287]  [<ffffffff81685c59>] schedule+0x29/0x70
[  860.827289]  [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0
[  860.827291]  [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0
[  860.827294]  [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70
[  860.827296]  [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140
[  860.827298]  [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20
[  860.827301]  [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150
[  860.827303]  [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110
[  860.827305]  [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160  [rt2x00usb]
[  860.827307]  [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb]
[  860.827309]  [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb]
[  860.827311]  [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
[  860.827314]  [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50  [rt2800lib]
[  860.827321]  [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0  [mac80211]
[  860.827322]  [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80
[  860.827329]  [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211]

Cc: stable@vger.kernel.org
Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com>
Reported-and-tested-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>