kernel/linux.git/drivers/net/ethernet/amd, branch v7.1

pcnet32: stop holding device spin lock during napi_complete_done

2026-06-02T18:26:30+00:00

napi_complete_done may call gro_flush_normal (though not currently, as GRO is unsupported at the moment), which may result in packet TX. This will eventually result in calling pcnet32_start_xmit - resulting in a deadlock while trying to re-acquire the already locked spin lock. It is safe to split the spinlock block into two, because the hardware registers are still protected from concurrent access, and the two blocks perform unrelated operations that don't need to happen atomically. Fixes: 5b2ec6f2be51 ("pcnet32: use napi_complete_done()") Reviewed-by: Andrew Lunn Signed-off-by: Oscar Maes Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260528140320.5556-1-oscmaes92@gmail.com Signed-off-by: Jakub Kicinski

pds_core: ensure null-termination for firmware version strings

2026-05-21T15:21:11+00:00

The driver passes fw_version directly to devlink_info_version_stored_put() without ensuring null-termination. While current firmware null-terminates these strings, the driver should not rely on this behavior. Add explicit null-termination to prevent potential issues if firmware behavior changes. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260520205842.1486718-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski

pds_core: fix debugfs_lookup dentry leak and error handling

2026-05-20T02:18:33+00:00

debugfs_lookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery. Additionally, when CONFIG_DEBUG_FS is disabled, debugfs_lookup() returns ERR_PTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash. Fixes: bc90fbe0c318 ("pds_core: Rework teardown/setup flow to be more common") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260515212907.998028-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski

pds_core: fix error handling in pdsc_devcmd_wait

2026-05-20T02:12:42+00:00

Fix two cases where pdsc_devcmd_wait() returns stale success from the completion register instead of an error: 1. FW crash: If firmware stops running, the wait loop breaks early with running=false. The condition "if ((!done || timeout) && running)" is false, so error handling is bypassed and stale status is returned. Check !running first and return -ENXIO. 2. Timeout: If a command times out, err is set to -ETIMEDOUT but then overwritten by pdsc_err_to_errno(status) which reads stale status. Return -ETIMEDOUT immediately after cleaning up. Both errors now propagate to pdsc_devcmd_locked() which queues health_work for recovery. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260515212907.998028-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski

amd-xgbe: fix PTP addend overflow causing frozen clock

2026-05-02T17:16:27+00:00

XGBE_PTP_ACT_CLK_FREQ and XGBE_V2_PTP_ACT_CLK_FREQ were 10x too large (500MHz/1GHz instead of 50MHz/100MHz), causing the computed addend to overflow the 32-bit tstamp_addend. In the general case this would result in the clock advancing at the wrong rate. For v2 (PCI), ptpclk_rate is hardcoded to 125MHz, so the addend formula (ACT_CLK_FREQ << 32) / ptpclk_rate yields exactly 8 * 2^32, and when stored to the 32-bit tstamp_addend the value is zero. With addend = 0 the hardware accumulator never overflows and the PTP clock is fully stopped. For v1 (platform), ptpclk_rate is read from ACPI/DT so the exact overflow behavior depends on the firmware-reported frequency. Define the constants as NSEC_PER_SEC / SSINC so the relationship is explicit and cannot drift out of sync. Fixes: fbd47be098b5 ("amd-xgbe: add hardware PTP timestamping support") Tested-by: Gregory Fuchedgi Signed-off-by: Gregory Fuchedgi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260429-fix-xgbe-ptp-addend-v1-1-fca5b0ca5e62@gmail.com Signed-off-by: Jakub Kicinski

drivers: net: amd: nmclan: Remove this driver

2026-04-23T22:56:49+00:00

The nmclan was written by Roger C Pao in 1995. It is an PCMCIA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-6-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski

drivers: net: amd: lance: Remove this driver

2026-04-23T22:56:49+00:00

The lance was written by Donald Becker between 1993-1998. It is an ISA device, so unlikely to be used with modern kernels. Signed-off-by: Andrew Lunn Link: https://patch.msgid.link/20260422-v7-0-0-net-next-driver-removal-v1-v2-5-08a5b59784d5@lunn.ch Signed-off-by: Jakub Kicinski

declance: Include the offending address with DMA errors

2026-04-01T02:32:41+00:00

The address latched in the I/O ASIC LANCE DMA Pointer Register uses the TURBOchannel bus address encoding and therefore bits 33:29 of location referred occupy bits 4:0, bits 28:2 are left-shifted by 3, and bits 1:0 are hardwired to zero. In reality no TURBOchannel system exceeds 1GiB of RAM though, so the address reported will always fit in 8 hex digits. Signed-off-by: Maciej W. Rozycki Link: https://patch.msgid.link/alpine.DEB.2.21.2603291839220.60268@angie.orcam.me.uk Signed-off-by: Jakub Kicinski

declance: Rate-limit DMA errors

2026-04-01T02:32:41+00:00

Prevent the system from becoming unusable due to a flood of DMA error messages. Signed-off-by: Maciej W. Rozycki Link: https://patch.msgid.link/alpine.DEB.2.21.2603291838370.60268@angie.orcam.me.uk Signed-off-by: Jakub Kicinski

amd-xgbe: add TX descriptor cleanup for link-down

2026-03-24T09:48:07+00:00

Add intelligent TX descriptor cleanup mechanism to reclaim abandoned descriptors when the physical link goes down. When the link goes down while TX packets are in-flight, the hardware stops processing descriptors with the OWN bit still set. The current driver waits indefinitely for these descriptors to complete, which never happens. This causes: - TX ring exhaustion (no descriptors available for new packets) - Memory leaks (skbs never freed) - DMA mapping leaks (mappings never unmapped) - Network stack backpressure buildup Add force-cleanup mechanism in xgbe_tx_poll() that detects link-down state and reclaims abandoned descriptors. The helper functions and DMA optimizations support efficient TX shutdown: - xgbe_wait_for_dma_tx_complete(): Wait for DMA completion with link-down optimization - Restructure xgbe_disable_tx() for proper shutdown sequence Implementation: 1. Check link state at the start of tx_poll 2. If link is down, set force_cleanup flag 3. For descriptors that hardware hasn't completed (!tx_complete): - If force_cleanup: treat as completed and reclaim resources - If link up: break and wait for hardware (normal behavior) The cleanup process: - Frees skbs that will never be transmitted - Unmaps DMA mappings - Resets descriptors for reuse - Does NOT count as successful transmission (correct statistics) Benefits: - Prevents TX ring starvation - Eliminates memory and DMA mapping leaks - Enables fast link recovery when link comes back up - Critical for link aggregation failover scenarios Signed-off-by: Raju Rangoju Link: https://patch.msgid.link/20260319163251.1808611-4-Raju.Rangoju@amd.com Signed-off-by: Paolo Abeni