linux-stable.git/drivers, branch v5.16.6

e1000e: Handshake with CSME starts from ADL platforms

2022-02-05T11:39:58+00:00

commit cad014b7b5a6897d8c4fad13e2888978bfb7a53f upstream.

Handshake with CSME/AMT on none provisioned platforms during S0ix flow
is not supported on TGL platform and can cause to HW unit hang. Update
the handshake with CSME flow to start from the ADL platform.

Fixes: 3e55d231716e ("e1000e: Add handshake with the CSME to support S0ix")
Signed-off-by: Sasha Neftin 
Tested-by: Nechama Kraus 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

net: ipa: request IPA register values be retained

2022-02-05T11:39:57+00:00

commit 34a081761e4e3c35381cbfad609ebae2962fe2f8 upstream.

In some cases, the IPA hardware needs to request the always-on
subsystem (AOSS) to coordinate with the IPA microcontroller to
retain IPA register values at power collapse.  This is done by
issuing a QMP request to the AOSS microcontroller.  A similar
request ondoes that request.

We must get and hold the "QMP" handle early, because we might get
back EPROBE_DEFER for that.  But the actual request should be sent
while we know the IPA clock is active, and when we know the
microcontroller is operational.

Fixes: 1aac309d3207 ("net: ipa: use autosuspend")
Signed-off-by: Alex Elder 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: amd-xgbe: Fix skb data length underflow

2022-02-05T11:39:57+00:00

commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee upstream.

There will be BUG_ON() triggered in include/linux/skbuff.h leading to
intermittent kernel panic, when the skb length underflow is detected.

Fix this by dropping the packet if such length underflows are seen
because of inconsistencies in the hardware descriptors.

Fixes: 622c36f143fc ("amd-xgbe: Fix jumbo MTU processing on newer hardware")
Suggested-by: Tom Lendacky 
Signed-off-by: Shyam Sundar S K 
Acked-by: Tom Lendacky 
Link: https://lore.kernel.org/r/20220127092003.2812745-1-Shyam-sundar.S-k@amd.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: amd-xgbe: ensure to reset the tx_timer_active flag

2022-02-05T11:39:57+00:00

commit 7674b7b559b683478c3832527c59bceb169e701d upstream.

Ensure to reset the tx_timer_active flag in xgbe_stop(),
otherwise a port restart may result in tx timeout due to
uncleared flag.

Fixes: c635eaacbf77 ("amd-xgbe: Remove Tx coalescing")
Co-developed-by: Sudheesh Mavila 
Signed-off-by: Sudheesh Mavila 
Signed-off-by: Raju Rangoju 
Acked-by: Tom Lendacky 
Link: https://lore.kernel.org/r/20220127060222.453371-1-Raju.Rangoju@amd.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

i40e: Fix reset path while removing the driver

2022-02-05T11:39:57+00:00

commit 6533e558c6505e94c3e0ed4281ed5e31ec985f4d upstream.

Fix the crash in kernel while dereferencing the NULL pointer,
when the driver is unloaded and simultaneously the VSI rings
are being stopped.

The hardware requires 50msec in order to finish RX queues
disable. For this purpose the driver spins in mdelay function
for the operation to be completed.

For example changing number of queues which requires reset would
fail in the following call stack:

1) i40e_prep_for_reset
2) i40e_pf_quiesce_all_vsi
3) i40e_quiesce_vsi
4) i40e_vsi_close
5) i40e_down
6) i40e_vsi_stop_rings
7) i40e_vsi_control_rx -> disable requires the delay of 50msecs
8) continue back in i40e_down function where
   i40e_clean_tx_ring(vsi->tx_rings[i]) is going to crash

When the driver was spinning vsi_release called
i40e_vsi_free_arrays where the vsi->tx_rings resources
were freed and the pointer was set to NULL.

Fixes: 5b6d4a7f20b0 ("i40e: Fix crash during removing i40e driver")
Signed-off-by: Slawomir Laba 
Signed-off-by: Sylwester Dziedziuch 
Signed-off-by: Karen Sornek 
Tested-by: Gurucharan G 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

i40e: Fix reset bw limit when DCB enabled with 1 TC

2022-02-05T11:39:57+00:00

commit 3d2504663c41104b4359a15f35670cfa82de1bbf upstream.

There was an AQ error I40E_AQ_RC_EINVAL when trying
to reset bw limit as part of bw allocation setup.
This was caused by trying to reset bw limit with
DCB enabled. Bw limit should not be reset when
DCB is enabled. The code was relying on the pf->flags
to check if DCB is enabled but if only 1 TC is available
this flag will not be set even though DCB is enabled.
Add a check for number of TC and if it is 1
don't try to reset bw limit even if pf->flags shows
DCB as disabled.

Fixes: fa38e30ac73f ("i40e: Fix for Tx timeouts when interface is brought up if DCB is enabled")
Suggested-by: Alexander Lobakin  # Flatten the condition
Signed-off-by: Sylwester Dziedziuch 
Signed-off-by: Jedrzej Jagielski 
Reviewed-by: Alexander Lobakin 
Tested-by: Imam Hassan Reza Biswas 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman

ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback

2022-02-05T11:39:57+00:00

commit 63e4b45c82ed1bde979da7052229a4229ce9cabf upstream.

When rx_buf is allocated we need to account for IPHETH_IP_ALIGN,
which reduces the usable size by 2 bytes. Otherwise we have 1512
bytes usable instead of 1514, and if we receive more than 1512
bytes, ipheth_rcvbulk_callback is called with status -EOVERFLOW,
after which the driver malfunctiones and all communication stops.

Resolves ipheth 2-1:4.2: ipheth_rcvbulk_callback: urb status: -75

Fixes: f33d9e2b48a3 ("usbnet: ipheth: fix connectivity with iOS 14")
Signed-off-by: Georgi Valkov 
Tested-by: Jan Kiszka 
Link: https://lore.kernel.org/all/B60B8A4B-92A0-49B3-805D-809A2433B46C@abv.bg/
Link: https://lore.kernel.org/all/24851bd2769434a5fc24730dce8e8a984c5a4505.1643699778.git.jan.kiszka@siemens.com/
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net/mlx5e: Avoid implicit modify hdr for decap drop rule

2022-02-05T11:39:56+00:00

commit 5b209d1a22afabfb7d644abb10510c5713a3e569 upstream.

Currently the driver adds implicit modify hdr action for
decap rules on tunnel devices if the port is an ovs port.
This is also done if the action is drop and makes the modify
hdr redundant and also the FW doesn't support it and will generate
a syndrome.

kernel: mlx5_core 0000:08:00.0: mlx5_cmd_check:777:(pid 102063): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x8708c3)

Fix it by adding the implicit modify hdr only for fwd actions.

Fixes: b16eb3c81fe2 ("net/mlx5: Support internal port as decap route device")
Fixes: 077cdda764c7 ("net/mlx5e: TC, Fix memory leak with rules with internal port")
Signed-off-by: Roi Dayan 
Reviewed-by: Ariel Levkovich 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Greg Kroah-Hartman

net/mlx5: E-Switch, Fix uninitialized variable modact

2022-02-05T11:39:56+00:00

commit d8e5883d694bb053b19c4142a2d1f43a34f6fe2c upstream.

The variable modact is not initialized before used in command
modify header allocation which can cause command to fail.

Fix by initializing modact with zeros.

Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 8f1e0b97cc70 ("net/mlx5: E-Switch, Mark miss packets with new chain id mapping")
Signed-off-by: Maor Dickman 
Reviewed-by: Roi Dayan 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Greg Kroah-Hartman

net/mlx5e: Fix broken SKB allocation in HW-GRO

2022-02-05T11:39:56+00:00

commit 7957837b816f11eecb9146235bb0715478f4c81f upstream.

In case the HW doesn't perform header-data split, it will write the whole
packet into the data buffer in the WQ, in this case the SHAMPO CQE handler
couldn't use the header entry to build the SKB, instead it should allocate
a new memory to build the SKB using the function:
mlx5e_skb_from_cqe_mpwrq_nonlinear.

Fixes: f97d5c2a453e ("net/mlx5e: Add handle SHAMPO cqe support")
Signed-off-by: Khalid Manaa 
Reviewed-by: Tariq Toukan 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Greg Kroah-Hartman