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

net: qed: RDMA personality shouldn't fail VF load

2020-10-01T11:18:18+00:00

[ Upstream commit ce1cf9e5025f4e2d2198728391f1847b3e168bc6 ]

Fix the assert during VF driver installation when the personality is iWARP

Fixes: 1fe614d10f45 ("qed: Relax VF firmware requirements")
Signed-off-by: Igor Russkikh 
Signed-off-by: Michal Kalderon 
Signed-off-by: Dmitry Bogdanov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: qede: Disable aRFS for NPAR and 100G

2020-10-01T11:18:18+00:00

[ Upstream commit 0367f05885b9f21d062447bd2ba1302ba3cc7392 ]

In some configurations ARFS cannot be used, so disable it if device
is not capable.

Fixes: e4917d46a653 ("qede: Add aRFS support")
Signed-off-by: Manish Chopra 
Signed-off-by: Igor Russkikh 
Signed-off-by: Michal Kalderon 
Signed-off-by: Dmitry Bogdanov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: qed: Disable aRFS for NPAR and 100G

2020-10-01T11:18:18+00:00

[ Upstream commit 2d2fe8433796603091ac8ea235b9165ac5a85f9a ]

In CMT and NPAR the PF is unknown when the GFS block processes the
packet. Therefore cannot use searcher as it has a per PF database,
and thus ARFS must be disabled.

Fixes: d51e4af5c209 ("qed: aRFS infrastructure support")
Signed-off-by: Manish Chopra 
Signed-off-by: Igor Russkikh 
Signed-off-by: Michal Kalderon 
Signed-off-by: Dmitry Bogdanov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

mwifiex: Increase AES key storage size to 256 bits

2020-10-01T11:18:16+00:00

[ Upstream commit 4afc850e2e9e781976fb2c7852ce7bac374af938 ]

Following commit e18696786548 ("mwifiex: Prevent memory corruption
handling keys") the mwifiex driver fails to authenticate with certain
networks, specifically networks with 256 bit keys, and repeatedly asks
for the password. The kernel log repeats the following lines (id and
bssid redacted):

    mwifiex_pcie 0000:01:00.0: info: trying to associate to '' bssid 
    mwifiex_pcie 0000:01:00.0: info: associated to bssid  successfully
    mwifiex_pcie 0000:01:00.0: crypto keys added
    mwifiex_pcie 0000:01:00.0: info: successfully disconnected from : reason code 3

Tracking down this problem lead to the overflow check introduced by the
aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This
check fails on networks with 256 bit keys due to the current storage
size for AES keys in struct mwifiex_aes_param being only 128 bit.

To fix this issue, increase the storage size for AES keys to 256 bit.

Fixes: e18696786548 ("mwifiex: Prevent memory corruption handling keys")
Signed-off-by: Maximilian Luz 
Reported-by: Kaloyan Nikolov 
Tested-by: Kaloyan Nikolov 
Reviewed-by: Dan Carpenter 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.com
Signed-off-by: Sasha Levin

ieee802154/adf7242: check status of adf7242_read_reg

2020-10-01T11:18:16+00:00

[ Upstream commit e3914ed6cf44bfe1f169e26241f8314556fd1ac1 ]

Clang static analysis reports this error

adf7242.c:887:6: warning: Assigned value is garbage or undefined
        len = len_u8;
            ^ ~~~~~~

len_u8 is set in
       adf7242_read_reg(lp, 0, &len_u8);

When this call fails, len_u8 is not set.

So check the return code.

Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")

Signed-off-by: Tom Rix 
Acked-by: Michael Hennerich 
Link: https://lore.kernel.org/r/20200802142339.21091-1-trix@redhat.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin

ieee802154: fix one possible memleak in ca8210_dev_com_init

2020-10-01T11:18:16+00:00

[ Upstream commit 88f46b3fe2ac41c381770ebad9f2ee49346b57a2 ]

We should call destroy_workqueue to destroy mlme_workqueue in error branch.

Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: Liu Jian 
Link: https://lore.kernel.org/r/20200720143315.40523-1-liujian56@huawei.com
Signed-off-by: Stefan Schmidt 
Signed-off-by: Sasha Levin

mt76: fix LED link time failure

2020-10-01T11:18:11+00:00

[ Upstream commit d68f4e43a46ff1f772ff73085f96d44eb4163e9d ]

The mt76_led_cleanup() function is called unconditionally, which
leads to a link error when CONFIG_LEDS is a loadable module or
disabled but mt76 is built-in:

drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_unregister_device':
mac80211.c:(.text+0x2ac): undefined reference to `led_classdev_unregister'

Use the same trick that is guarding the registration, using an
IS_ENABLED() check for the CONFIG_MT76_LEDS symbol that indicates
whether LEDs can be used or not.

Fixes: 36f7e2b2bb1d ("mt76: do not use devm API for led classdev")
Signed-off-by: Arnd Bergmann 
Acked-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

wlcore: fix runtime pm imbalance in wlcore_regdomain_config

2020-10-01T11:18:07+00:00

[ Upstream commit 282a04bf1d8029eb98585cb5db3fd70fe8bc91f7 ]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
Acked-by: Tony Lindgren 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200520124649.10848-1-dinghao.liu@zju.edu.cn
Signed-off-by: Sasha Levin

wlcore: fix runtime pm imbalance in wl1271_tx_work

2020-10-01T11:18:07+00:00

[ Upstream commit 9604617e998b49f7695fea1479ed82421ef8c9f0 ]

There are two error handling paths in this functon. When
wlcore_tx_work_locked() returns an error code, we should
decrease the runtime PM usage counter the same way as the
error handling path beginning from pm_runtime_get_sync().

Signed-off-by: Dinghao Liu 
Acked-by: Tony Lindgren 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200520124241.9931-1-dinghao.liu@zju.edu.cn
Signed-off-by: Sasha Levin

e1000: Do not perform reset in reset_task if we are already down

2020-10-01T11:18:03+00:00

[ Upstream commit 49ee3c2ab5234757bfb56a0b3a3cb422f427e3a3 ]

We are seeing a deadlock in e1000 down when NAPI is being disabled. Looking
over the kernel function trace of the system it appears that the interface
is being closed and then a reset is hitting which deadlocks the interface
as the NAPI interface is already disabled.

To prevent this from happening I am disabling the reset task when
__E1000_DOWN is already set. In addition code has been added so that we set
the __E1000_DOWN while holding the __E1000_RESET flag in e1000_close in
order to guarantee that the reset task will not run after we have started
the close call.

Signed-off-by: Alexander Duyck 
Tested-by: Maxim Zhukov 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin