<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net/wireless, branch v4.20</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.20</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.20'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2018-12-19T16:39:18Z</updated>
<entry>
<title>Merge tag 'wireless-drivers-for-davem-2018-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers</title>
<updated>2018-12-19T16:39:18Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2018-12-19T16:39:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c6f4075e2f14a91f2180c98bc7715946f791cbe6'/>
<id>urn:sha1:c6f4075e2f14a91f2180c98bc7715946f791cbe6</id>
<content type='text'>
Kalle Valo says:

====================
wireless-drivers fixes for 4.20

Last set of fixes for 4.20. All (except the mt76 fix) of these are
important fixes to user reported problems and pretty small in size.

rtlwifi

* fix skb leak

mwifiex

* revert a commit from v4.19 due to problems with locking

mt76

* fix a potential NULL derenfence

* add entry to MAINTAINERS

iwlwifi

* fix a firmware crash which was a regression introduced in v4.20-rc4

ath10k

* fix a firmware crash with wcn3990 firmware
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ath10k: skip sending quiet mode cmd for WCN3990</title>
<updated>2018-12-19T13:37:01Z</updated>
<author>
<name>Rakesh Pillai</name>
<email>pillair@codeaurora.org</email>
</author>
<published>2018-12-14T10:17:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=53884577fbcef33a7d15ad664e664a3dabe35171'/>
<id>urn:sha1:53884577fbcef33a7d15ad664e664a3dabe35171</id>
<content type='text'>
HL2.0 firmware does not support setting quiet mode.  If the host driver sends
the quiet mode setting command to the HL2.0 firmware, it crashes with the below
signature.

fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN RT:207a:PC=b001b4f0

The quiet mode command support is exposed by the firmware via thermal throttle
wmi service. Enable ath10k thermal support if thermal throttle wmi service bit
is set.  10.x firmware versions support this feature by default, but
unfortunately do not advertise the support via service flags, hence have to
manually set the service flag in ath10k_core_compat_services().

Tested on QCA988X with 10.2.4.70.9-2. Also tested on WCN3990.

Co-developed-by: Govind Singh &lt;govinds@codeaurora.org&gt;
Co-developed-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Rakesh Pillai &lt;pillair@codeaurora.org&gt;
Signed-off-by: Govind Singh &lt;govinds@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares</title>
<updated>2018-12-17T13:15:22Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2018-12-14T16:30:22Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=eca1e56ceedd9cc185eb18baf307d3ff2e4af376'/>
<id>urn:sha1:eca1e56ceedd9cc185eb18baf307d3ff2e4af376</id>
<content type='text'>
Old firmware versions don't support this command. Sending it
to any firmware before -41.ucode will crash the firmware.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201975

Fixes: 66e839030fd6 ("iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE")
CC: &lt;stable@vger.kernel.org&gt; #4.19+
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>mt76: fix potential NULL pointer dereference in mt76_stop_tx_queues</title>
<updated>2018-12-13T14:19:56Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo.bianconi@redhat.com</email>
</author>
<published>2018-11-16T16:19:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7c250f4612ae97aa04500c0d0cff69bb87046e3a'/>
<id>urn:sha1:7c250f4612ae97aa04500c0d0cff69bb87046e3a</id>
<content type='text'>
Starting from mac80211 commit adf8ed01e4fd ("mac80211: add an optional
TXQ for other PS-buffered frames") and commit 0eeb2b674f05 ("mac80211:
add an option for station management TXQ") a new per-sta queue has been
introduced for bufferable management frames.
sta-&gt;txq[IEEE80211_NUM_TIDS] is initialized just if the driver reports
the following hw flags:
- IEEE80211_HW_STA_MMPDU_TXQ
- IEEE80211_HW_BUFF_MMPDU_TXQ
This can produce a NULL pointer dereference in mt76_stop_tx_queues
since mt76 iterates on all available sta tx queues assuming they are
initialized by mac80211. This issue has been spotted analyzing the code
(it has not triggered any crash yet)

Signed-off-by: Lorenzo Bianconi &lt;lorenzo.bianconi@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>Revert "mwifiex: restructure rx_reorder_tbl_lock usage"</title>
<updated>2018-12-13T13:53:27Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2018-11-30T17:59:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1aa48f088615ebfa5e139951a0d3e7dc2c2af4ec'/>
<id>urn:sha1:1aa48f088615ebfa5e139951a0d3e7dc2c2af4ec</id>
<content type='text'>
This reverts commit 5188d5453bc9380ccd4ae1086138dd485d13aef2, because it
introduced lock recursion:

  BUG: spinlock recursion on CPU#2, kworker/u13:1/395
   lock: 0xffffffc0e28a47f0, .magic: dead4ead, .owner: kworker/u13:1/395, .owner_cpu: 2
  CPU: 2 PID: 395 Comm: kworker/u13:1 Not tainted 4.20.0-rc4+ #2
  Hardware name: Google Kevin (DT)
  Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]
  Call trace:
   dump_backtrace+0x0/0x140
   show_stack+0x20/0x28
   dump_stack+0x84/0xa4
   spin_bug+0x98/0xa4
   do_raw_spin_lock+0x5c/0xdc
   _raw_spin_lock_irqsave+0x38/0x48
   mwifiex_flush_data+0x2c/0xa4 [mwifiex]
   call_timer_fn+0xcc/0x1c4
   run_timer_softirq+0x264/0x4f0
   __do_softirq+0x1a8/0x35c
   do_softirq+0x54/0x64
   netif_rx_ni+0xe8/0x120
   mwifiex_recv_packet+0xfc/0x10c [mwifiex]
   mwifiex_process_rx_packet+0x1d4/0x238 [mwifiex]
   mwifiex_11n_dispatch_pkt+0x190/0x1ac [mwifiex]
   mwifiex_11n_rx_reorder_pkt+0x28c/0x354 [mwifiex]
   mwifiex_process_sta_rx_packet+0x204/0x26c [mwifiex]
   mwifiex_handle_rx_packet+0x15c/0x16c [mwifiex]
   mwifiex_rx_work_queue+0x104/0x134 [mwifiex]
   worker_thread+0x4cc/0x72c
   kthread+0x134/0x13c
   ret_from_fork+0x10/0x18

This was clearly not tested well at all. I simply performed 'wget' in a
loop and it fell over within a few seconds.

Fixes: 5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage")
Cc: &lt;stable@vger.kernel.org&gt;
Cc: Ganapathi Bhat &lt;gbhat@marvell.com&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>rtlwifi: Fix leak of skb when processing C2H_BT_INFO</title>
<updated>2018-12-13T13:35:07Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2018-11-18T02:55:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8cfa272b0d321160ebb5b45073e39ef0a6ad73f2'/>
<id>urn:sha1:8cfa272b0d321160ebb5b45073e39ef0a6ad73f2</id>
<content type='text'>
With commit 0a9f8f0a1ba9 ("rtlwifi: fix btmpinfo timeout while processing
C2H_BT_INFO"), calling rtl_c2hcmd_enqueue() with rtl_c2h_fast_cmd() true,
the routine returns without freeing that skb, thereby leaking it.

This issue has been discussed at https://github.com/lwfinger/rtlwifi_new/issues/401
and the fix tested there.

Fixes: 0a9f8f0a1ba9 ("rtlwifi: fix btmpinfo timeout while processing C2H_BT_INFO")
Reported-and-tested-by: Francisco Machado Magalhães Neto &lt;franmagneto@gmail.com&gt;
Cc: Francisco Machado Magalhães Neto &lt;franmagneto@gmail.com&gt;
Cc: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt; # 4.18+
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'mac80211-for-davem-2018-12-05' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211</title>
<updated>2018-12-05T19:46:06Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2018-12-05T19:46:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=64d47902fea3dcd3f2d0f3366259984dbc31653b'/>
<id>urn:sha1:64d47902fea3dcd3f2d0f3366259984dbc31653b</id>
<content type='text'>
Johannes Berg:

====================
As it's been a while, we have various fixes for
 * hwsim
 * AP mode (client powersave related)
 * CSA/FTM interaction
 * a busy loop in IE handling
 * and similar
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mt76: fix uninitialized mutex access setting rts threshold</title>
<updated>2018-11-16T13:15:49Z</updated>
<author>
<name>Lorenzo Bianconi</name>
<email>lorenzo.bianconi@redhat.com</email>
</author>
<published>2018-11-10T11:03:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1770f0fa978ed691a454fa9d3ba903d5a70630cc'/>
<id>urn:sha1:1770f0fa978ed691a454fa9d3ba903d5a70630cc</id>
<content type='text'>
Fix following crash due to a leftover uninitialized mutex access
in mt76x2_set_rts_threshold routine.

[   31.018059] Call Trace:
[   31.018341]  register_lock_class+0x51f/0x530
[   31.018828]  __lock_acquire+0x6c/0x1580
[   31.019247]  lock_acquire+0x88/0x120
[   31.021089]  __mutex_lock+0x4a/0x4f0
[   31.023343]  mt76x2_set_rts_threshold+0x28/0x50
[   31.023831]  ieee80211_set_wiphy_params+0x16d/0x4e0
[   31.024344]  nl80211_set_wiphy+0x72b/0xbc0
[   31.024781]  genl_family_rcv_msg+0x192/0x3a0
[   31.025233]  genl_rcv_msg+0x42/0x89
[   31.026079]  netlink_rcv_skb+0x38/0x100
[   31.026475]  genl_rcv+0x1f/0x30
[   31.026804]  netlink_unicast+0x19c/0x250
[   31.027212]  netlink_sendmsg+0x1ed/0x390
[   31.027615]  sock_sendmsg+0x31/0x40
[   31.027973]  ___sys_sendmsg+0x23c/0x280
[   31.030414]  __sys_sendmsg+0x42/0x80
[   31.030783]  do_syscall_64+0x4a/0x170
[   31.031160]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   31.031677] RIP: 0033:0x7f3498b39ba7
[   31.033953] RSP: 002b:00007fffe19675b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[   31.034883] RAX: ffffffffffffffda RBX: 00000000012d5350 RCX: 00007f3498b39ba7
[   31.035756] RDX: 0000000000000000 RSI: 00007fffe19675f0 RDI: 0000000000000003
[   31.036587] RBP: 00000000012da740 R08: 0000000000000002 R09: 0000000000000000
[   31.037422] R10: 0000000000000006 R11: 0000000000000246 R12: 00000000012da880
[   31.038252] R13: 00007fffe19675f0 R14: 00007fffe19678c0 R15: 00000000012da880

Fixes: 108a4861ef19 ("mt76: create new mt76x02-lib module for common mt76x{0,2} code")
Reported-by: lorenzo.trisolini@fluidmesh.com
Reported-by: luca.bisti@fluidmesh.com
Signed-off-by: Lorenzo Bianconi &lt;lorenzo.bianconi@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>brcmfmac: fix reporting support for 160 MHz channels</title>
<updated>2018-11-16T13:10:18Z</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2018-11-08T15:08:29Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d1fe6ad6f6bd61c84788d3a7b11e459a439c6169'/>
<id>urn:sha1:d1fe6ad6f6bd61c84788d3a7b11e459a439c6169</id>
<content type='text'>
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid &amp; complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.

This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.

Signed-off-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
<entry>
<title>ath10k: don't assume 'vif' is non-NULL in flush()</title>
<updated>2018-11-16T13:07:42Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2018-11-08T00:40:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d987f783a4808ce0636f58e2412addd453cba88c'/>
<id>urn:sha1:d987f783a4808ce0636f58e2412addd453cba88c</id>
<content type='text'>
mac80211 may call us with vif == NULL, if the station is not currently
active (e.g., not associated). It is trivially easy to reproduce a crash
by suspending the system when not connected to an AP:

[   65.533934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
...
[   65.574521] pc : ath10k_flush+0x30/0xd0 [ath10k_core]
[   65.574538] lr : __ieee80211_flush_queues+0x180/0x244 [mac80211]
[   65.599680] Process kworker/u12:1 (pid: 57, stack limit = 0x(____ptrval____))
[   65.599682] Call trace:
[   65.599695]  ath10k_flush+0x30/0xd0 [ath10k_core]
[   65.642064]  __ieee80211_flush_queues+0x180/0x244 [mac80211]
[   65.642079]  ieee80211_flush_queues+0x34/0x40 [mac80211]
[   65.642095]  __ieee80211_suspend+0xfc/0x47c [mac80211]
[   65.658611]  ieee80211_suspend+0x30/0x3c [mac80211]
[   65.658627]  wiphy_suspend+0x15c/0x3a8 [cfg80211]
[   65.672810]  dpm_run_callback+0xf0/0x1f0
[   65.672814]  __device_suspend+0x3ac/0x4f8
[   65.672819]  async_suspend+0x34/0xbc
[   65.684096]  async_run_entry_fn+0x54/0x104
[   65.684099]  worker_thread+0x4cc/0x72c
[   65.684102]  kthread+0x134/0x13c
[   65.684105]  ret_from_fork+0x10/0x18

Fixes: 9de4162f0999 ("ath10k: add peer flush in ath10k_flush for STATION")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
</entry>
</feed>
