u-boot.git/drivers/net/zynq_gem.c, branch master Unnamed repository; edit this file 'description' to name the repository. net: zynq_gem: Add support for dma-coherent flag 2026-03-23T13:58:46+00:00 Michal Simek michal.simek@amd.com 2026-03-02T07:43:34+00:00 6ead1d0b0fe5243c0f512f5468862cfa4ea6bfef When dma-coherent DT property is passed there is no need to do any cache operations. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/10c7a40364162cc8d3c82cb3e64e043f49a5153e.1772437409.git.michal.simek@amd.com 
When dma-coherent DT property is passed there is no need to do any cache
operations.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/10c7a40364162cc8d3c82cb3e64e043f49a5153e.1772437409.git.michal.simek@amd.com
net: zynq_gem: clear TXSR transfer complete 2026-03-23T13:58:46+00:00 Padmarao Begari padmarao.begari@amd.com 2026-03-02T07:43:33+00:00 0d96ce69d40b45e50f0ec38d02f20d6493c969e6 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 <harini.katakam@amd.com> Signed-off-by: Harini Katakam <harini.katakam@amd.com> Co-developed-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Padmarao Begari <padmarao.begari@amd.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/f354680d43fba0f590a6fae693848e5bf7114ba5.1772437409.git.michal.simek@amd.com 
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 <harini.katakam@amd.com>
Signed-off-by: Harini Katakam <harini.katakam@amd.com>
Co-developed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/f354680d43fba0f590a6fae693848e5bf7114ba5.1772437409.git.michal.simek@amd.com
net: zynq_gem: Disable broadcast packets 2026-03-23T13:58:46+00:00 Michal Simek michal.simek@amd.com 2026-03-02T07:43:32+00:00 3371da09c5709984533e307c8fde4e935945f435 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 <michal.simek@amd.com> Link: https://lore.kernel.org/r/6e10793b7d72668343756edb66221f1415570250.1772437409.git.michal.simek@amd.com 
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 <michal.simek@amd.com>
Link: https://lore.kernel.org/r/6e10793b7d72668343756edb66221f1415570250.1772437409.git.michal.simek@amd.com
drivers: net: Add versal2 10GBE device support 2025-10-09T07:07:03+00:00 Venkatesh Yadav Abbarapu venkatesh.abbarapu@amd.com 2025-08-28T04:58:07+00:00 038580206d44007dc105a80458cb582d1e9adabc 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 <venkatesh.abbarapu@amd.com> Link: https://lore.kernel.org/r/20250828045807.426542-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
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 <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20250828045807.426542-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
net: gem: ignore tx_clk if MII is used 2025-06-02T07:13:49+00:00 Martin Kaistra martin.kaistra@linutronix.de 2025-04-15T15:04:00+00:00 6759bd73e9cf491c5049f87b84e627920efb5824 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 <martin.kaistra@linutronix.de> Link: https://lore.kernel.org/r/20250415150400.136723-1-martin.kaistra@linutronix.de Signed-off-by: Michal Simek <michal.simek@amd.com> 
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 <martin.kaistra@linutronix.de>
Link: https://lore.kernel.org/r/20250415150400.136723-1-martin.kaistra@linutronix.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
net: gem: Remove undocumented is-internal-pcspma dt flag 2024-09-20T13:31:19+00:00 Michal Simek michal.simek@amd.com 2024-09-13T07:37:38+00:00 6161eaf05794ab2fc1af2b0159083ab6b955e20c 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 <michal.simek@amd.com> Link: https://lore.kernel.org/r/2ecdbcc4ce692e2f8b3e7054a2abab35f6c03a69.1726213052.git.michal.simek@amd.com 
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 <michal.simek@amd.com>
Link: https://lore.kernel.org/r/2ecdbcc4ce692e2f8b3e7054a2abab35f6c03a69.1726213052.git.michal.simek@amd.com
drivers: net: Remove duplicate newlines 2024-07-22T16:53:05+00:00 Marek Vasut marek.vasut+renesas@mailbox.org 2024-07-20T12:40:45+00:00 f3974bec32f7627e123d9005f2c70b9a004aa857 Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> 
Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" 2024-05-20T19:35:03+00:00 Tom Rini trini@konsulko.com 2024-05-20T19:35:03+00:00 03de305ec48b0bb28554372abb40ccd46dbe0bf9 As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" 2024-05-19T14:16:36+00:00 Tom Rini trini@konsulko.com 2024-05-19T02:20:43+00:00 d678a59d2d719da9e807495b4b021501f2836ca5 When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
net: Remove <common.h> and add needed includes 2024-05-07T14:00:55+00:00 Tom Rini trini@konsulko.com 2024-05-02T01:31:02+00:00 0e407c7420c4fefd7f7e6cc7c81eeec6d084f9e4 Remove <common.h> from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com> 
Remove <common.h> from this driver directory and when needed
add missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>