kernel/drivers/net/wireless, branch linux-5.1.y

rt2x00usb: fix rx queue hang

2019-07-26T07:13:03Z

commit 41a531ffa4c5aeb062f892227c00fabb3b4a9c91 upstream. Since commit ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler") the handler rt2x00usb_interrupt_rxdone() is not running with interrupts disabled anymore. So this completion handler is not guaranteed to run completely before workqueue processing starts for the same queue entry. Be sure to set all other flags in the entry correctly before marking this entry ready for workqueue processing. This way we cannot miss error conditions that need to be signalled from the completion handler to the worker thread. Note that rt2x00usb_work_rxdone() processes all available entries, not only such for which queue_work() was called. This patch is similar to what commit df71c9cfceea ("rt2x00: fix order of entry flags modification") did for TX processing. This fixes a regression on a RT5370 based wifi stick in AP mode, which suddenly stopped data transmission after some period of heavy load. Also stopping the hanging hostapd resulted in the error message "ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush". Other operation modes are probably affected as well, this just was the used testcase. Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Soeren Moch Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: clear rfkill_safe_init_done when we start the firmware

2019-07-26T07:12:57Z

commit 940225628652b340b2bfe99f42f3d2db9fd9ce6c upstream. Otherwise it'll stay set forever which is clearly buggy. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: delay GTK setting in FW in AP mode

2019-07-26T07:12:57Z

commit c56e00a3feaee2b46b7d33875fb7f52efd30241f upstream. In AP (and IBSS) mode, we can only set GTKs to firmware after we have sent down the multicast station, but this we can only do after we've enabled beaconing, etc. However, during rfkill exit, hostapd will configure the keys before starting the AP, and cfg80211/mac80211 accept it happily. On earlier devices, this didn't bother us as GTK TX wasn't really handled in firmware, we just put the key material into the TX cmd and thus it only mattered when we actually transmitted a frame. On newer devices, however, the firmware needs to track all of this and that doesn't work if we add the key before the (multicast) sta it belongs to. To fix this, keep a list of keys to add during AP enable, and call the function there. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices

2019-07-26T07:12:57Z

commit ed3e4c6d3cd8f093a3636cb05492429fe2af228d upstream. Newest devices have a new firmware load mechanism. This mechanism is called the context info. It means that the driver doesn't need to load the sections of the firmware. The driver rather prepares a place in DRAM, with pointers to the relevant sections of the firmware, and the firmware loads itself. At the end of the process, the firmware sends the ALIVE interrupt. This is different from the previous scheme in which the driver expected the FH_TX interrupt after each section being transferred over the DMA. In order to support this new flow, we enabled all the interrupts. This broke the assumption that we have in the code that the RF-Kill interrupt can't interrupt the firmware load flow. Change the context info flow to enable only the ALIVE interrupt, and re-enable all the other interrupts only after the firmware is alive. Then, we won't see the RF-Kill interrupt until then. Getting the RF-Kill interrupt while loading the firmware made us kill the firmware while it is loading and we ended up dumping garbage instead of the firmware state. Re-enable the ALIVE | RX interrupts from the ISR when we get the ALIVE interrupt to be able to get the RX interrupt that comes immediately afterwards for the ALIVE notification. This is needed for non MSI-X only. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman

iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-Kill

2019-07-26T07:12:57Z

commit 0d53cfd0cca3c729a089c39eef0e7d8ae7662974 upstream. iwl_mvm_send_cmd returns 0 when the command won't be sent because RF-Kill is asserted. Do the same when we call iwl_get_shared_mem_conf since it is not sent through iwl_mvm_send_cmd but directly calls the transport layer. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X

2019-07-26T07:12:57Z

commit ec46ae30245ecb41d73f8254613db07c653fb498 upstream. We added code to restock the buffer upon ALIVE interrupt when MSI-X is disabled. This was added as part of the context info code. This code was added only if the ISR debug level is set which is very unlikely to be related. Move this code to run even when the ISR debug level is not set. Note that gen2 devices work with MSI-X in most cases so that this path is seldom used. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: don't service an interrupt that was masked

2019-07-26T07:12:56Z

commit 3b57a10ca14c619707398dc58fe5ece18c95b20b upstream. Sometimes the register status can include interrupts that were masked. We can, for example, get the RF-Kill bit set in the interrupt status register although this interrupt was masked. Then if we get the ALIVE interrupt (for example) that was not masked, we need to *not* service the RF-Kill interrupt. Fix this in the MSI-X interrupt handler. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman

iwlwifi: add support for hr1 RF ID

2019-07-26T07:12:56Z

commit 498d3eb5bfbb2e05e40005152976a7b9eadfb59c upstream. The 22000 series FW that was meant to be used with hr is also the FW that is used for hr1 and has a different RF ID. Add support to load the hr FW when hr1 RF ID is detected. Cc: stable@vger.kernel.org # 5.1+ Signed-off-by: Oren Givon Signed-off-by: Luciano Coelho Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

iwlwifi: dbg: fix debug monitor stop and restart delays

2019-07-26T07:12:47Z

[ Upstream commit fc838c775f35e272e5cc7ef43853f0b55babbe37 ] The driver should delay only in recording stop flow between writing to DBGC_IN_SAMPLE register and DBGC_OUT_CTRL register. Any other delay is not needed. Change the following: 1. Remove any unnecessary delays in the flow 2. Increase the delay in the stop recording flow since 100 micro is not enough 3. Use usleep_range instead of delay since the driver is allowed to sleep in this flow. Signed-off-by: Shahar S Matityahu Fixes: 5cfe79c8d92a ("iwlwifi: fw: stop and start debugging using host command") Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin

iwlwifi: mvm: Drop large non sta frames

2019-07-26T07:12:47Z

[ Upstream commit ac70499ee97231a418dc1a4d6c9dc102e8f64631 ] In some buggy scenarios we could possible attempt to transmit frames larger than maximum MSDU size. Since our devices don't know how to handle this, it may result in asserts, hangs etc. This can happen, for example, when we receive a large multicast frame and try to transmit it back to the air in AP mode. Since in a legal scenario this should never happen, drop such frames and warn about it. Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin