In case an rswitch port is described as disabled in DT, do not
register it as ethernet device in U-Boot. This way, such ports
cannot be accessed from U-Boot command line.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

TFTP transfers of large files, for example 128 MiB, can sporadically
get stuck and the transfer slows down considerably.

This happens because the TX DMA descriptor in DRAM becomes out of sync
with the view of the TX DMA descriptor content from the CPU side, which
is viewed through the CPU caches. In order to guarantee these two views
are consistent, the cache over TX DMA descriptor that has possibly been
written by the rswitch hardware must first be invalidated, only then can
the descriptor be cleared and updated by the CPU, and finally the cache
over that area must be flushed back into DRAM to make sure the rswitch
hardware has consistent view of the updated descriptor content.

The very first invalidation operation was missing, which led to sporadic
corruption of the TX DMA descriptor. Fix it, add the missing invalidation
operation.

Reported-by: Enric Balletbo i Serra <eballetb@redhat.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>

We can call dev_read_u32_default() instead of calling fdt_getprop() then
fdt32_to_cpu().

Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

They were added with commit 0e9d23945ce0 ("net: eqos: implement callbaks
to get interface and set txclk rate") but were not removed with
commit 5fc783b5d9c9 ("net: dwc_eth_qos: move i.MX code out") when i.MX
specific code was moved to a separate file.

Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>

The EQOS on i.MX93 fails to finish the reset procedure in RMII mode.
This is described in errata ERR051683. This patch implements the
provided workaround which sets the PS and FES bits after the SWR is set
by using the eqos_fix_soc_reset function.

Adapted from linux-kernel commit b536f32b5b03 ("net: stmmac: dwmac-imx:
use platform specific reset for imx93 SoCs")

Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>

This patch adds support for optional platform specific reset logic in
the dwc_eth_qos driver. This new function 'eqos_fix_soc_reset' is called
after the EQOS_DMA_MODE_SWR is set and before the driver waits for this
bit to clear.

Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>

This patch series by Hanyuan Zhao <hanyuan-z@qq.com> provides a number of
improvements to the dc2114x driver.

Link: https://lore.kernel.org/r/tencent_BD4B002FC63A5F77969D9BD1FFF125371C08@qq.com

Romain Naour <romain.naour@smile.fr> says:

We are using a custom board where an ethernet switch device KSZ9896 is
available. This family of devices can use several types of serial bus
as management interface: mdio, i2c or SPI. Due to board design
constraints and because we initially planned to use this device only
from Linux, the SPI bus was used.

Luckily we are using a recent enough u-boot release where KSZ9477
driver is available... but only for the i2c interface. Indeed, unlike
the kernel driver, the KSZ9477 driver doesn't use the regmap API to
access the underlying bus since the regmap API is limited to direct
memory access [1].

Until regmap API with bus support is available in U-boot, we introduced
struct ksz_phy_ops to store low-level ksz bus operations (I2C or SPI).

This series has been tested on the current master branch (after v2024.10
release).

[1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.10-rc5/drivers/core/Kconfig?ref_type=tags#L188

Link: https://lore.kernel.org/r/20241008075435.1572727-1-romain.naour@smile.fr

Frank Sae <Frank.Sae@motor-comm.com> says:

YT8531 as Gigabit transceiver uses bit15:14(bit9 reserved default 0) as phy
speed mask, YT8821 as 2.5 Gigabit transceiver uses bit9 bit15:14 as phy
speed mask.

Be compatible to YT8821, reform phy speed mask and phy speed macro.

Based on update above, add YT8821 2.5G phy driver.

Link: https://lore.kernel.org/r/20240912120225.28884-1-Frank.Sae@motor-comm.com

Some drivers do not behave properly when free_pkt() is called with a
length of zero. It is an issue I observed when developing the lwIP
series [1] (see "QEMU CI tests for r2dplus_i82557c, r2dplus_rtl8139"
in the change log) and which I fixed incorrectly by not calling
free_pkt() when recv() returns 0. That turned out to be wrong for two
reasons:

1. The DM documentation [2] clearly requires it:

  "The **recv** function polls for availability of a new packet. [...]
   If there is an error [...], return 0 if you require the packet to
   be cleaned up normally, or a negative error code otherwise (cleanup
   not necessary or already done).

   If **free_pkt** is defined, U-Boot will call it after a received
   packet has been processed [...]. free_pkt() will be called after
   recv(), for the same packet [...]"

2. The imx8mp_evk platform will fail with OOM errors if free_pkt() is
   not called after recv() returns 0:

   u-boot=> tftp 192.168.0.16:50M
   Using ethernet@30be0000 device
   TFTP from server 192.168.0.16; our IP address is 192.168.0.48
   Filename '50M'.
   Load address: 0x40480000
   Loading: #######################fecmxc_recv: error allocating packetp
   fecmxc_recv: error allocating packetp
   fecmxc_recv: error allocating packetp
   ...

Therefore, make recv() return -EAGAIN instead of 0 when no packet is
available and the driver doesn't expect free_pkt() to be called
subsequently.

[1] https://lists.denx.de/pipermail/u-boot/2024-August/562861.html
[2] doc/develop/driver-model/ethernet.rst

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>