u-boot.git/drivers/net/fm, branch v2022.01

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

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

2021-09-28T15:50:56Z

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

global: Convert simple_strtoul() with hex to hextoul()

2021-08-02T17:32:14Z

It is a pain to have to specify the value 16 in each call. Add a new hextoul() function and update the code to use it. Add a proper comment to simple_strtoul() while we are here. Signed-off-by: Simon Glass

ppc: Remove T4160RDB board

2021-07-07T23:52:24Z

This board has not been converted to CONFIG_DM_PCI by the deadline and is also missing conversion to CONFIG_DM. Remove it. As this is the last ARCH_T4160 platform, remove that support as well. Signed-off-by: Tom Rini

ppc: Remove T1023RBD boards and T1024RDB_SECURE_BOOT

2021-07-07T23:52:23Z

These boards have not been converted to CONFIG_DM_PCI by the deadline and is also missing conversion to CONFIG_DM. Remove them. As this is the only ARCH_T1023 platform left, remove that support as well. Cc: Priyanka Jain Signed-off-by: Tom Rini

Fix a memory leak issue in the RX port initialization.

2021-06-18T08:29:17Z

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

ppc: Remove Cyrus_P5020 and P5040 boards

2021-04-10T12:05:07Z

These boards have not been converted to CONFIG_DM_MMC by the deadline. Remove them. As the P5020 is the last ARCH_P5020 platform, remove that support as well. Cc: Andy Fleming Cc: Priyanka Jain Signed-off-by: Tom Rini Reviewed-by: Priyanka Jain

ppc: Remove T2081QDS board and ARCH_T2081 support

2021-04-10T12:04:42Z

This board has not been converted to CONFIG_DM_MMC by the deadline. Remove it. It is also the only ARCH_T2081 board so remove that support as well. Cc: Shengzhou Liu Cc: Ruchika Gupta Signed-off-by: Tom Rini

net: memac_phy: add a timeout to MDIO operations

2021-02-08T08:31:14Z

We have encountered circumstances when a board design does not include pull-up resistors on the external MDIO buses which are not used. This leads to the MDIO data line not being pulled-up, thus the MDIO controller will always see the line as busy. Without a timeout in the MDIO bus driver, the execution is stuck in an infinite loop when any access is initiated on that external bus. Add a timeout in the driver so that we are protected in this circumstance. This is similar to what is being done in the Linux xgmac_mdio driver. Signed-off-by: Ioana Ciornei Reviewed-by: Madalin Bucur [Rebased] Signed-off-by: Priyanka Jain

dm: core: Access device ofnode through functions

2021-01-05T19:24:41Z

At present ofnode is present in the device even if it is never used. With of-platdata this field is not used, so can be removed. In preparation for this, change the access to go through inline functions. Signed-off-by: Simon Glass