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

scsi: ufs: ufs-exynos: Correct timeout value setting registers

2021-11-02T18:48:25+00:00

[ Upstream commit 282da7cef078a87b6d5e8ceba8b17e428cf0e37c ]

PA_PWRMODEUSERDATA0 -> DL_FC0PROTTIMEOUTVAL
PA_PWRMODEUSERDATA1 -> DL_TC0REPLAYTIMEOUTVAL
PA_PWRMODEUSERDATA2 -> DL_AFC0REQTIMEOUTVAL

Link: https://lore.kernel.org/r/20211018062841.18226-1-chanho61.park@samsung.com
Fixes: a967ddb22d94 ("scsi: ufs: ufs-exynos: Apply vendor-specific values for three timeouts")
Cc: Alim Akhtar 
Cc: Kiwoong Kim 
Cc: Krzysztof Kozlowski 
Reviewed-by: Alim Akhtar 
Reviewed-by: Avri Altman 
Signed-off-by: Chanho Park 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

lan743x: fix endianness when accessing descriptors

2021-11-02T18:48:24+00:00

[ Upstream commit 462512824f902a24de794290dd622e664587da1d ]

TX/RX descriptor ring fields are always little-endian, but conversion
wasn't performed for big-endian CPUs, so the driver failed to work.

This patch makes the driver work on big-endian CPUs. It was tested and
confirmed to work on NXP P1010 processor (PowerPC).

Signed-off-by: Alexey Denisov 
Link: https://lore.kernel.org/r/20210128044859.280219-1-rtgbnm@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

phy: phy_ethtool_ksettings_set: Lock the PHY while changing settings

2021-11-02T18:48:24+00:00

commit af1a02aa23c37045e6adfcf074cf7dbac167a403 upstream.

There is a race condition where the PHY state machine can change
members of the phydev structure at the same time userspace requests a
change via ethtool. To prevent this, have phy_ethtool_ksettings_set
take the PHY lock.

Fixes: 2d55173e71b0 ("phy: add generic function to support ksetting support")
Reported-by: Walter Stoll 
Suggested-by: Walter Stoll 
Tested-by: Walter Stoll 
Signed-off-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

phy: phy_start_aneg: Add an unlocked version

2021-11-02T18:48:24+00:00

commit 707293a56f95f8e7e0cfae008010c7933fb68973 upstream.

Split phy_start_aneg into a wrapper which takes the PHY lock, and a
helper doing the real work. This will be needed when
phy_ethtook_ksettings_set takes the lock.

Fixes: 2d55173e71b0 ("phy: add generic function to support ksetting support")
Signed-off-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

phy: phy_ethtool_ksettings_set: Move after phy_start_aneg

2021-11-02T18:48:23+00:00

commit 64cd92d5e8180c2ded3fdea76862de6f596ae2c9 upstream.

This allows it to make use of a helper which assume the PHY is already
locked.

Fixes: 2d55173e71b0 ("phy: add generic function to support ksetting support")
Signed-off-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

phy: phy_ethtool_ksettings_get: Lock the phy for consistency

2021-11-02T18:48:23+00:00

commit c10a485c3de5ccbf1fff65a382cebcb2730c6b06 upstream.

The PHY structure should be locked while copying information out if
it, otherwise there is no guarantee of self consistency. Without the
lock the PHY state machine could be updating the structure.

Fixes: 2d55173e71b0 ("phy: add generic function to support ksetting support")
Signed-off-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: nxp: lpc_eth.c: avoid hang when bringing interface down

2021-11-02T18:48:23+00:00

commit ace19b992436a257d9a793672e57abc28fe83e2e upstream.

A hard hang is observed whenever the ethernet interface is brought
down. If the PHY is stopped before the LPC core block is reset,
the SoC will hang. Comparing lpc_eth_close() and lpc_eth_open() I
re-arranged the ordering of the functions calls in lpc_eth_close() to
reset the hardware before stopping the PHY.
Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
Signed-off-by: Trevor Woerner 
Acked-by: Vladimir Zapolskiy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ethernet: microchip: lan743x: Fix dma allocation failure by using dma_set_mask_and_coherent

2021-11-02T18:48:23+00:00

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
https://github.com/raspberrypi/linux/issues/4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ethernet: microchip: lan743x: Fix driver crash when lan743x_pm_resume fails

2021-11-02T18:48:23+00:00

commit d6423d2ec39cce2bfca418c81ef51792891576bc upstream.

The driver needs to clean up and return when the initialization fails on resume.

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlxsw: pci: Recycle received packet upon allocation failure

2021-11-02T18:48:23+00:00

commit 759635760a804b0d8ad0cc677b650f1544cae22f upstream.

When the driver fails to allocate a new Rx buffer, it passes an empty Rx
descriptor (contains zero address and size) to the device and marks it
as invalid by setting the skb pointer in the descriptor's metadata to
NULL.

After processing enough Rx descriptors, the driver will try to process
the invalid descriptor, but will return immediately seeing that the skb
pointer is NULL. Since the driver no longer passes new Rx descriptors to
the device, the Rx queue will eventually become full and the device will
start to drop packets.

Fix this by recycling the received packet if allocation of the new
packet failed. This means that allocation is no longer performed at the
end of the Rx routine, but at the start, before tearing down the DMA
mapping of the received packet.

Remove the comment about the descriptor being zeroed as it is no longer
correct. This is OK because we either use the descriptor as-is (when
recycling) or overwrite its address and size fields with that of the
newly allocated Rx buffer.

The issue was discovered when a process ("perf") consumed too much
memory and put the system under memory pressure. It can be reproduced by
injecting slab allocation failures [1]. After the fix, the Rx queue no
longer comes to a halt.

[1]
 # echo 10 > /sys/kernel/debug/failslab/times
 # echo 1000 > /sys/kernel/debug/failslab/interval
 # echo 100 > /sys/kernel/debug/failslab/probability

 FAULT_INJECTION: forcing a failure.
 name failslab, interval 1000, probability 100, space 0, times 8
 [...]
 Call Trace:
  
  dump_stack_lvl+0x34/0x44
  should_fail.cold+0x32/0x37
  should_failslab+0x5/0x10
  kmem_cache_alloc_node+0x23/0x190
  __alloc_skb+0x1f9/0x280
  __netdev_alloc_skb+0x3a/0x150
  mlxsw_pci_rdq_skb_alloc+0x24/0x90
  mlxsw_pci_cq_tasklet+0x3dc/0x1200
  tasklet_action_common.constprop.0+0x9f/0x100
  __do_softirq+0xb5/0x252
  irq_exit_rcu+0x7a/0xa0
  common_interrupt+0x83/0xa0
  
  asm_common_interrupt+0x1e/0x40
 RIP: 0010:cpuidle_enter_state+0xc8/0x340
 [...]
 mlxsw_spectrum2 0000:06:00.0: Failed to alloc skb for RDQ

Fixes: eda6500a987a ("mlxsw: Add PCI bus implementation")
Signed-off-by: Ido Schimmel 
Reviewed-by: Petr Machata 
Link: https://lore.kernel.org/r/20211024064014.1060919-1-idosch@idosch.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman