linux-stable.git/drivers/net, branch v5.4.7

iwlwifi: pcie: move power gating workaround earlier in the flow

2019-12-31T15:46:35+00:00

commit 0df36b90c47d93295b7e393da2d961b2f3b6cde4 upstream.

We need to reset the NIC after setting the bits to enable power
gating and that cannot be done too late in the flow otherwise it
cleans other registers and things that were already configured,
causing initialization to fail.

In order to fix this, move the function to the common code in trans.c
so it can be called directly from there at an earlier point, just
after the reset we already do during initialization.

Fixes: 9a47cb988338 ("iwlwifi: pcie: add workaround for power gating in integrated 22000")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205719
Cc: stable@ver.kernel.org # 5.4+
Reported-by: Anders Kaseorg 
Signed-off-by: Luca Coelho 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

can: flexcan: add low power enter/exit acknowledgment helper

2019-12-31T15:46:05+00:00

[ Upstream commit b7603d080ffcf8689ec91ca300caf84d8dbed317 ]

The MCR[LPMACK] read-only bit indicates that FlexCAN is in a lower-power
mode (Disabled mode, Doze mode, Stop mode).

The CPU can poll this bit to know when FlexCAN has actually entered low
power mode. The low power enter/exit acknowledgment helper will reduce
code duplication for disabled mode, doze mode and stop mode.

Tested-by: Sean Nyekjaer 
Signed-off-by: Joakim Zhang 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

ath10k: Revert "ath10k: add cleanup in ath10k_sta_state()"

2019-12-31T15:46:00+00:00

[ Upstream commit f4fe2e53349f1072d33c69f484dbf9d77bb8f45a ]

This reverts commit 334f5b61a6f29834e881923b98d1e27e5ce9620d.

This caused ath10k_snoc on Qualcomm MSM8998, SDM845 and QCS404 platforms to
trigger an assert in the firmware:

err_qdi.c:456:EF:wlan_process:1:cmnos_thread.c:3900:Asserted in wlan_vdev.c:_wlan_vdev_up:3219

Revert the offending commit for now.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

can: kvaser_usb: kvaser_usb_leaf: Fix some info-leaks to USB devices

2019-12-31T15:45:58+00:00

commit da2311a6385c3b499da2ed5d9be59ce331fa93e9 upstream.

Uninitialized Kernel memory can leak to USB devices.

Fix this by using kzalloc() instead of kmalloc().

Signed-off-by: Xiaolong Huang 
Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c")
Cc: linux-stable  # >= v4.19
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment

2019-12-31T15:45:57+00:00

commit 048e3a34a2e7669bf475eb56c7345ad9d8d2b8e3 upstream.

Stop Mode is entered when Stop Mode is requested at chip level and
MCR[LPM_ACK] is asserted by the FlexCAN.

Double check with IP owner, the MCR[LPM_ACK] bit should be polled for
stop mode acknowledgment, not the acknowledgment from chip level which
is used to gate flexcan clocks.

This patch depends on:

    b7603d080ffc ("can: flexcan: add low power enter/exit acknowledgment helper")

Fixes: 5f186c257fa4 (can: flexcan: fix stop mode acknowledgment)
Tested-by: Sean Nyekjaer 
Signed-off-by: Joakim Zhang 
Cc: linux-stable  # >= v5.0
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: flexcan: fix possible deadlock and out-of-order reception after wakeup

2019-12-31T15:45:56+00:00

commit e707180ae2df1c87e26ec7a6fd70d07483bde7fd upstream.

When suspending, and there is still CAN traffic on the interfaces the
flexcan immediately wakes the platform again. As it should :-). But it
throws this error msg:

[ 3169.378661] PM: noirq suspend of devices failed

On the way down to suspend the interface that throws the error message
calls flexcan_suspend() but fails to call flexcan_noirq_suspend(). That
means flexcan_enter_stop_mode() is called, but on the way out of suspend
the driver only calls flexcan_resume() and skips flexcan_noirq_resume(),
thus it doesn't call flexcan_exit_stop_mode(). This leaves the flexcan
in stop mode, and with the current driver it can't recover from this
even with a soft reboot, it requires a hard reboot.

This patch fixes the deadlock when using self wakeup, by calling
flexcan_exit_stop_mode() from flexcan_resume() instead of
flexcan_noirq_resume().

This also fixes another issue: CAN frames are received out-of-order in
first IRQ handler run after wakeup.

The problem is that the wakeup latency from frame reception to the IRQ
handler (where the CAN frames are sorted by timestamp) is much bigger
than the time stamp counter wrap around time. This means it's
impossible to sort the CAN frames by timestamp.

The reason is that the controller exits stop mode during noirq resume,
which means it receives frames immediately, but interrupt handling is
still not possible.

So exit stop mode during resume stage instead of noirq resume fixes this
issue.

Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
Signed-off-by: Sean Nyekjaer 
Tested-by: Sean Nyekjaer 
Signed-off-by: Joakim Zhang 
Cc: linux-stable  # >= v5.0
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: m_can: tcan4x5x: add required delay after reset

2019-12-31T15:45:56+00:00

commit 60552253e29c8860ee5bf1e6064591b0917c0394 upstream.

According to section "8.3.8 RST Pin" in the datasheet we are required to
wait >700us after the device is reset.

Signed-off-by: Sean Nyekjaer 
Acked-by: Dan Murphy 
Cc: linux-stable  # >= v5.4
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

can: xilinx_can: Fix missing Rx can packets on CANFD2.0

2019-12-31T15:45:55+00:00

commit 9ab79b06ddf3cdf6484d60b3e5fe113e733145c8 upstream.

CANFD2.0 core uses BRAM for storing acceptance filter ID(AFID) and MASK
(AFMASK)registers. So by default AFID and AFMASK registers contain random
data. Due to random data, we are not able to receive all CAN ids.

Initializing AFID and AFMASK registers with Zero before enabling
acceptance filter to receive all packets irrespective of ID and Mask.

Fixes: 0db9071353a0 ("can: xilinx: add can 2.0 support")
Signed-off-by: Michal Simek 
Signed-off-by: Srinivas Neeli 
Reviewed-by: Naga Sureshkumar Relli 
Cc: linux-stable  # >= v5.0
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

net: wireless: intel: iwlwifi: fix GRO_NORMAL packet stalling

2019-12-31T15:45:49+00:00

[ Upstream commit b167191e2a851cb2e4c6ef8b91c83ff73ef41872 ]

Commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()") has applied batched GRO_NORMAL packets processing
to all napi_gro_receive() users, including mac80211-based drivers.

However, this change has led to a regression in iwlwifi driver [1][2] as
it is required for NAPI users to call napi_complete_done() or
napi_complete() and the end of every polling iteration, whilst iwlwifi
doesn't use NAPI scheduling at all and just calls napi_gro_flush().
In that particular case, packets which have not been already flushed
from napi->rx_list stall in it until at least next Rx cycle.

Fix this by adding a manual flushing of the list to iwlwifi driver right
before napi_gro_flush() call to mimic napi_complete() logics.

I prefer to open-code gro_normal_list() rather than exporting it for 2
reasons:
* to prevent from using it and napi_gro_flush() in any new drivers,
  as it is the *really* bad way to use NAPI that should be avoided;
* to keep gro_normal_list() static and don't lose any CC optimizations.

I also don't add the "Fixes:" tag as the mentioned commit was only a
trigger that only exposed an improper usage of NAPI in this particular
driver.

[1] https://lore.kernel.org/netdev/PSXP216MB04388962C411CD0B17A86F47804A0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205647

Signed-off-by: Alexander Lobakin 
Acked-by: Luca Coelho 
Reported-by: Nicholas Johnson 
Tested-by: Nicholas Johnson 
Reviewed-by: Edward Cree 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

ibmvnic: Fix completion structure initialization

2019-12-31T15:45:49+00:00

[ Upstream commit 070eca955c4af1248cb78a216463ff757a5dc511 ]

Fix multiple calls to init_completion for device completion
structures. Instead, initialize them during device probe and
reinitialize them later as needed.

Signed-off-by: Thomas Falcon 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin