u-boot.git/drivers/net/phy, branch v2022.04

net: phy: add TI DP83869HM ethernet driver

2022-01-15T16:50:16+00:00

This driver is based on an older downstream TI kernel, with
changes and cleanups to work with mainline device-tree bindings.

Signed-off-by: Dominic Rath 
Signed-off-by: Christian Gmeiner 
Reviewed-by: Ramon Fried

Convert CONFIG_ENV_SPI_BUS et al to Kconfig

2021-12-27T13:40:33+00:00

This converts the following to Kconfig:
   CONFIG_ENV_SPI_BUS
   CONFIG_ENV_SPI_CS
   CONFIG_ENV_SPI_MAX_HZ
   CONFIG_ENV_SPI_MODE

As part of this, we use Kconfig to provide the defaults now that were
done in include/spi_flash.h.  We also in some cases change from using
CONFIG_ENV_SPI_FOO to CONFIG_SF_DEFAULT_FOO as those were the values in
use anyhow as ENV was not enabled.

Signed-off-by: Tom Rini

net: phy: realtek: Add tx/rx delay config for 8211e

2021-11-23T07:57:56+00:00

Some boards need to change the tx/rx delay config in order for
gigabit Ethernet to work.

In Linux commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), Realtek documented the bits for overriding the delays
from the hardware straps.

Copy the logic from linux, so the delay config is set from the PHY's
interface type (the phy-mode property in the device tree).

This removes the need for a one-off workaround for the Pine A64+ board.

Signed-off-by: Samuel Holland 
Reviewed-by: Ramon Fried

net: phy: mscc: add support for VSC8502 in dual RGMII mode

2021-11-23T07:57:55+00:00

The VSC8502 is a Microchip (formerly Microsemi, formerly Vitesse)
dual port, gigabit Ethernet copper PHY which supports the MII, GMII and
RGMII MAC-side interfaces.

Of these, I could only test RGMII, and my board needed RGMII delays to
be applied by software, so I am able to confirm that this patch handles
that properly.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Ramon Fried

WS cleanup: remove trailing white space

2021-09-30T12:08:56+00:00

Signed-off-by: Wolfgang Denk 
Reviewed-by: Simon Glass

Merge branch 'network_master' of https://source.denx.de/u-boot/custodians/u-boot-net into next

2021-09-29T11:58:20+00:00

- Fix some non-NULL terminated strings in the networking subsystem
- net: tsec: Mark tsec_get_interface as __maybe_unused

net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"

2021-09-28T15:50:56+00:00

After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/

which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/

and many other discussions before it, notably:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/

it became apparent that nobody really knows what "SGMII 2500" is.
Certainly, Freescale/NXP hardware engineers name this protocol
"SGMII 2500" in the reference manuals, but the PCS devices do not
support any "SGMII" specific features when operating at the speed of
2500 Mbps, no in-band autoneg and no speed change via symbol replication
. So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
in-band autoneg and at a fixed speed" is indistinguishable from
"2500base-x without in-band autoneg", which is precisely what these NXP
devices support.

So it just appears that "SGMII 2500" is an unclear name with no clear
definition that stuck.

As such, in the Linux kernel, the drivers which use this SERDES protocol
use the 2500base-x phy-mode.

This patch converts U-Boot to use 2500base-x too, or at least, as much
as it can.

Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
completely, but the mvpp2 driver seems to even distinguish between SGMII
2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
the other, and forces flow control for one but not the other. This goes
back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
two are practically indistinguishable through everything except use case.

NXP devices can support both use cases through an identical configuration,
for example RX flow control can be unconditionally enabled in order to
support rate adaptation performed by an Aquantia PHY. At least I can
find no indication in online documents published by Cisco which would
point towards "SGMII-2500" being an actual standard with an actual
definition, so I cannot say "yes, NXP devices support it".

Signed-off-by: Vladimir Oltean
Reviewed-by: Ramon Fried

net: replace the "xfi" phy-mode with "10gbase-r"

2021-09-28T15:50:56+00:00

As part of the effort of making U-Boot work with the same device tree as
Linux, there is an issue with the "xfi" phy-mode. To be precise, in
Linux there was a discussion (for those who have time to read:
https://lore.kernel.org/netdev/1576768881-24971-2-git-send-email-madalin.bucur@oss.nxp.com/)

which led to a patch:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c114574ebfdf42f826776f717c8056a00fa94881

TL;DR: "xfi" was standardized in Linux as "10gbase-r".

This patch changes the relevant occurrences in U-Boot to use "10gbase-r"
instead of "xfi" wherever applicable.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Ramon Fried

net: phy: genphy_init can be static

2021-09-28T15:50:56+00:00

To avoid a warning with W=1 about this function not having a previous
prototype, declare it as static, because it is not used outside of this
translation module.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Bin Meng 
Reviewed-by: Ramon Fried

Kconfig: Remove all default n/no options

2021-08-31T21:47:49+00:00

default n/no doesn't need to be specified. It is default option anyway.

Signed-off-by: Michal Simek 
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini