u-boot.git/drivers/net/fm/eth.c, branch v2025.01

net: fm: call dtsec_init_phy() only when it is defined

2024-09-24T19:41:21Z

dtsec_init_phy() is defined only with MII so add the proper conditional in the caller code. Signed-off-by: Jerome Forissier Reviewed-by: Simon Glass

Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"

2024-05-20T19:35:03Z

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 Signed-off-by: Tom Rini

Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

2024-05-19T14:16:36Z

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 Signed-off-by: Tom Rini

net: Remove and add needed includes

2024-05-07T14:00:55Z

Remove from this driver directory and when needed add missing include files directly. Signed-off-by: Tom Rini

net: fm: Remove non-DM_ETH code

2022-12-07T21:04:16Z

As DM_ETH is required for all network drivers, it's now safe to remove the non-DM_ETH support code. Signed-off-by: Tom Rini

global: Move remaining CONFIG_SYS_* to CFG_SYS_*

2022-12-05T21:06:08Z

The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do not easily transition to Kconfig. In many cases they likely should come from the device tree instead. Move these out of CONFIG namespace and in to CFG namespace. Signed-off-by: Tom Rini Reviewed-by: Simon Glass

global: Migrate CONFIG_SYS_FSL* symbols to the CFG_SYS namespace

2022-11-10T15:08:55Z

Migrate all of COFIG_SYS_FSL* to the CFG_SYS namespace. Signed-off-by: Tom Rini Reviewed-by: Simon Glass

net: introduce helpers to get PHY interface mode from a device/ofnode

2022-04-10T05:44:12Z

Add helpers ofnode_read_phy_mode() and dev_read_phy_mode() to parse the "phy-mode" / "phy-connection-type" property. Add corresponding UT test. Use them treewide. This allows us to inline the phy_get_interface_by_name() into ofnode_read_phy_mode(), since the former is not used anymore. Signed-off-by: Marek Behún Reviewed-by: Ramon Fried Tested-by: Patrice Chotard

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

2021-09-28T15:50:56Z

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

Fix a memory leak issue in the RX port initialization.

2021-06-18T08:29:17Z

Signed-off-by: Hou Zhiqiang Reviewed-by: Ramon Fried