u-boot.git/drivers/net/zynq_gem.c, branch main

net: zynq_gem: Clear stale speed bits in NWCFG before setting new ones

2026-04-23T09:52:18Z

Commit ecba4380ad26 ("net: zynq_gem: Update the MDC clock divisor in the probe function") changed zynq_gem_init() from a direct register write to a read-modify-write pattern in order to preserve MDC clock divider bits. However, the old speed selection bits (SPEED100/SPEED1000) are never cleared before OR-ing in the new value. When the PHY renegotiates at a different speed between successive calls to zynq_gem_init() (e.g. link flapping from 1 Gbps to 100 Mbps on a marginal cable), both SPEED100 and SPEED1000 end up set simultaneously in NWCFG. This confuses the GEM hardware and no frames are received. Fix by explicitly clearing both speed bits before merging the new configuration, so only the currently negotiated speed is ever active. Fixes: ecba4380ad26 ("net: zynq_gem: Update the MDC clock divisor in the probe function") Signed-off-by: Rafał Hibner Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260420074640.4036119-1-rafal.hibner@secom.com.pl

net: zynq_gem: reinitialize RX BDs on every init

2026-04-23T09:49:48Z

Reinitialize RX BDs and rewrite rxqbase on every init instead of only on the first init. This ensures a clean BD state on every init for all GEM configurations. For AMD Versal Gen 2 10GBE this is required since the USX block resets the RX DMA pointer to rxqbase on each init, so BDs must be rebuilt each time to stay in sync with hardware. Signed-off-by: Pranav Tilak Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260410093018.1461732-4-pranav.vinaytilak@amd.com

net: zynq_gem: set 128-bit AXI bus width for 10GBE

2026-04-23T09:49:48Z

Set 128-bit AXI bus width in network config for 10GBE. The default 64-bit setting causes DMA data corruption. Signed-off-by: Pranav Tilak Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260410093018.1461732-3-pranav.vinaytilak@amd.com

net: zynq_gem: add SPEED_10000 case in clock rate selection

2026-04-23T09:49:48Z

Add SPEED_10000 case in the speed switch with the fixed 150 MHz tx_clk rate. Without this, clk_rate stays 0 for 10000 Mbps and clk_set_rate(0) on a fixed clock aborts initialization. Signed-off-by: Pranav Tilak Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/20260410093018.1461732-2-pranav.vinaytilak@amd.com

net: zynq_gem: Add support for dma-coherent flag

2026-03-23T13:58:46Z

When dma-coherent DT property is passed there is no need to do any cache operations. Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/10c7a40364162cc8d3c82cb3e64e043f49a5153e.1772437409.git.michal.simek@amd.com

net: zynq_gem: clear TXSR transfer complete

2026-03-23T13:58:46Z

The Zynq GEM TX status register retains the transfer‑complete bit until it is explicitly cleared. The current flow waits for transfer‑complete but never clears it, so on the next send the wait loop returns immediately because transfer‑complete is already high. This causes the driver to report TX completion before the new DMA transfer has actually finished, which breaks back‑to‑back transmissions. This issue causes timeouts during LWIP TFTP transfers when cache coherency is enabled. Fix this by explicitly clearing transfer‑complete (write‑to‑clear) after the wait completes, so each transmit starts with a clean TXSR. Co-developed-by: Harini Katakam Signed-off-by: Harini Katakam Co-developed-by: Michal Simek Signed-off-by: Padmarao Begari Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/f354680d43fba0f590a6fae693848e5bf7114ba5.1772437409.git.michal.simek@amd.com

net: zynq_gem: Disable broadcast packets

2026-03-23T13:58:46Z

There is no reason to react on broadcast packets that's why just ignore them not to waste cycles on packets which are not for the platform. Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/6e10793b7d72668343756edb66221f1415570250.1772437409.git.michal.simek@amd.com

drivers: net: Add versal2 10GBE device support

2025-10-09T07:07:03Z

Add 10GBE high-speed Mac support, it supports 10G, 5G, 2.5G and 1G speeds. 10GBE high speed Mac is an extension of the current 1G Mac in versal, inheriting all its current features. MMI 10GBE ip has two internal PCS's. 1)10GBASER PCS is used for higher speeds 10G and 5G. 2)1000BASEX PCS is used for slower speeds 1G and 2.5G. Both PCS's speed and rate configuration is done with same usx registers. ENABLE_HS_MAC bit in NCR is the toggle switch between the PCS's. Signed-off-by: Venkatesh Yadav Abbarapu Link: https://lore.kernel.org/r/20250828045807.426542-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek

net: gem: ignore tx_clk if MII is used

2025-06-02T07:13:49Z

If the MII interface is used, the PHY is the clock master, thus don't set the clock rate. On Zynq-7000, this will prevent the following error: zynq_gem ethernet@e000b000: failed to set tx clock rate 25000000 Signed-off-by: Martin Kaistra Link: https://lore.kernel.org/r/20250415150400.136723-1-martin.kaistra@linutronix.de Signed-off-by: Michal Simek

net: gem: Remove undocumented is-internal-pcspma dt flag

2024-09-20T13:31:19Z

Generic understanding/consideration is that phy-mode as sgmi means that the internal PCS(Physical Coding Sublayer) should be enabled by default. Xilinx GEM implementation allows configuration GEM (gmii mode) + PL PCS PMA (sgmii mode, Physical Medum Attachment) but in this case phy-mode should be setup as gmii. The reason for this assumption is that phy-mode should be described based on GEM configuration not based on mode coming out of PHY. Also Linux kernel automatically setting up PCSSEL bit when phy mode is sgmii without a need to specified additional DT propety. All our DTSes with sgmii phy mode have this flag enabled that's why there is no need/reason to just duplicate information. Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/2ecdbcc4ce692e2f8b3e7054a2abab35f6c03a69.1726213052.git.michal.simek@amd.com