linux-stable.git/drivers/net/ethernet/microchip, branch linux-5.15.y

net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X

2025-12-06T21:09:23+00:00

[ Upstream commit 6287982aa54946449bccff3e6488d3a15e458392 ]

LAN969x switchdev support depends on the SparX-5 core,so make it selectable
for ARCH_LAN969X.

Signed-off-by: Robert Marko 
Reviewed-by: Daniel Machon 
Link: https://patch.msgid.link/20250917110106.55219-1-robert.marko@sartura.hr
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: lan743x: rename lan743x_reset_phy to lan743x_hw_reset_phy

2025-06-27T10:05:14+00:00

[ Upstream commit 68927eb52d0af04863584930db06075d2610e194 ]

rename the function to lan743x_hw_reset_phy to better describe it
operation.

Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Thangaraj Samynathan 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/20250526053048.287095-2-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: lan743x: Fix memleak issue when GSO enabled

2025-05-09T07:39:40+00:00

[ Upstream commit 2d52e2e38b85c8b7bc00dca55c2499f46f8c8198 ]

Always map the `skb` to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Thangaraj Samynathan 
Reviewed-by: Jacob Keller 
Link: https://patch.msgid.link/20250429052527.10031-1-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: sparx5: fix the maximum frame length register

2024-12-19T17:07:20+00:00

[ Upstream commit ddd7ba006078a2bef5971b2dc5f8383d47f96207 ]

On port initialization, we configure the maximum frame length accepted
by the receive module associated with the port. This value is currently
written to the MAX_LEN field of the DEV10G_MAC_ENA_CFG register, when in
fact, it should be written to the DEV10G_MAC_MAXLEN_CFG register. Fix
this.

Fixes: 946e7fd5053a ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: sparx5: fix FDMA performance issue

2024-12-19T17:07:20+00:00

[ Upstream commit f004f2e535e2b66ccbf5ac35f8eaadeac70ad7b7 ]

The FDMA handler is responsible for scheduling a NAPI poll, which will
eventually fetch RX packets from the FDMA queue. Currently, the FDMA
handler is run in a threaded context. For some reason, this kills
performance.  Admittedly, I did not do a thorough investigation to see
exactly what causes the issue, however, I noticed that in the other
driver utilizing the same FDMA engine, we run the FDMA handler in hard
IRQ context.

Fix this performance issue, by  running the FDMA handler in hard IRQ
context, not deferring any work to a thread.

Prior to this change, the RX UDP performance was:

Interval           Transfer     Bitrate         Jitter
0.00-10.20  sec    44.6 MBytes  36.7 Mbits/sec  0.027 ms

After this change, the rx UDP performance is:

Interval           Transfer     Bitrate         Jitter
0.00-9.12   sec    1.01 GBytes  953 Mbits/sec   0.020 ms

Fixes: 10615907e9b5 ("net: sparx5: switchdev: adding frame DMA functionality")
Signed-off-by: Daniel Machon 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: sparx5: fix wrong config being used when reconfiguring PCS

2024-04-17T09:15:15+00:00

[ Upstream commit 33623113a48ea906f1955cbf71094f6aa4462e8f ]

The wrong port config is being used if the PCS is reconfigured. Fix this
by correctly using the new config instead of the old one.

Fixes: 946e7fd5053a ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon 
Reviewed-by: Jacob Keller 
Link: https://lore.kernel.org/r/20240409-link-mode-reconfiguration-fix-v2-1-db6a507f3627@microchip.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Sasha Levin

net: sparx5: Fix use after free inside sparx5_del_mact_entry

2024-03-15T14:48:14+00:00

[ Upstream commit 89d72d4125e94aa3c2140fedd97ce07ba9e37674 ]

Based on the static analyzis of the code it looks like when an entry
from the MAC table was removed, the entry was still used after being
freed. More precise the vid of the mac_entry was used after calling
devm_kfree on the mac_entry.
The fix consists in first using the vid of the mac_entry to delete the
entry from the HW and after that to free it.

Fixes: b37a1bae742f ("net: sparx5: add mactable support")
Signed-off-by: Horatiu Vultur 
Reviewed-by: Simon Horman 
Link: https://lore.kernel.org/r/20240301080608.3053468-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

ethernet: use eth_hw_addr_set() instead of ether_addr_copy()

2023-07-27T06:46:59+00:00

[ Upstream commit f3956ebb3bf06ab2266ad5ee2214aed46405810c ]

Convert Ethernet from ether_addr_copy() to eth_hw_addr_set():

  @@
  expression dev, np;
  @@
  - ether_addr_copy(dev->dev_addr, np)
  + eth_hw_addr_set(dev, np)

Signed-off-by: Jakub Kicinski 
Signed-off-by: David S. Miller 
Stable-dep-of: 1d6d537dc55d ("net: ethernet: mtk_eth_soc: handle probe deferral")
Signed-off-by: Sasha Levin

net: lan743x: Don't sleep in atomic context

2023-07-23T11:47:38+00:00

commit 7a8227b2e76be506b2ac64d2beac950ca04892a5 upstream.

dev_set_rx_mode() grabs a spin_lock, and the lan743x implementation
proceeds subsequently to go to sleep using readx_poll_timeout().

Introduce a helper wrapping the readx_poll_timeout_atomic() function
and use it to replace the calls to readx_polL_timeout().

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Cc: stable@vger.kernel.org
Cc: Bryan Whitehead 
Cc: UNGLinuxDriver@microchip.com
Signed-off-by: Moritz Fischer 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20230627035000.1295254-1-moritzf@google.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

net: sparx5: Fix reading of the MAC address

2023-01-12T10:59:14+00:00

[ Upstream commit 588ab2dc25f60efeb516b4abedb6c551949cc185 ]

There is an issue with the checking of the return value of
'of_get_mac_address', which returns 0 on success and negative value on
failure. The driver interpretated the result the opposite way. Therefore
if there was a MAC address defined in the DT, then the driver was
generating a random MAC address otherwise it would use address 0.
Fix this by checking correctly the return value of 'of_get_mac_address'

Fixes: b74ef9f9cb91 ("net: sparx5: Do not use mac_addr uninitialized in mchp_sparx5_probe()")
Signed-off-by: Horatiu Vultur 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin