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

spi: spi_flash_probe_bus_cs() rely on DT for spi speed and mode

2022-05-23T13:33:10Z

Now, spi_flash_probe_bus_cs() relies on DT for spi speed and mode and logically calls spi_get_bus_and_cs(). In case spi mode and speed are not read from DT, make usage of spi_flash_probe() instead. To sum-up: - Previous call tree was: spi_flash_probe() -> spi_flash_probe_bus_cs() -> spi_get_bus_and_cs() - Current call tree is: spi_flash_probe() -> _spi_get_bus_and_cs() spi_flash_probe_bus_cs() -> spi_get_bus_and_cs() This patch impacts the following : - cmd/sf.c: if spi mode and/or speed is passed in argument of do_spi_flash_probe(), call spi_flash_probe() otherwise call spi_flash_probe_bus_cs(). - drivers/net/fm/fm.c: as by default spi speed and mode was set to 0 and a comment indicates that speed and mode are read from DT, use spi_flash_probe_bus_cs(). - drivers/net/pfe_eth/pfe_firmware.c: spi speed and mode are not read from DT by all platforms using this driver, so keep legacy and replace spi_flash_probe_bus_cs() by spi_flash_probe(); - drivers/net/sni_netsec.c : spi speed and mode are not read from DT, so replace spi_flash_probe_bus_cs() by spi_flash_probe(). - drivers/usb/gadget/max3420_udc.c: Can't find any platform which make usage of this driver, nevertheless, keep legacy and replace spi_get_bus_and_cs() by _spi_get_bus_and_cs(). - env/sf.c: a comment indicates that speed and mode are read from DT. So use spi_flash_probe_bus_cs(). Signed-off-by: Patrice Chotard Cc: Marek Behun Cc: Jagan Teki Cc: Vignesh R Cc: Joe Hershberger Cc: Ramon Fried Cc: Lukasz Majewski Cc: Marek Vasut Cc: Wolfgang Denk Cc: Simon Glass Cc: Stefan Roese Cc: "Pali Rohár" Cc: Konstantin Porotchkin Cc: Igal Liberman Cc: Bin Meng Cc: Pratyush Yadav Cc: Sean Anderson Cc: Anji J Cc: Biwen Li Cc: Priyanka Jain Cc: Chaitanya Sakinam

treewide: Rename PHY_INTERFACE_MODE_NONE to PHY_INTERFACE_MODE_NA

2022-04-10T05:44:13Z

Rename constant PHY_INTERFACE_MODE_NONE to PHY_INTERFACE_MODE_NA to make it compatible with Linux' naming. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Reviewed-by: Ramon Fried Reviewed-by: Vladimir Oltean

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

fdt_support: Add fdt_for_each_node_by_compatible() helper macro

2022-01-20T10:35:29Z

Add macro fdt_for_each_node_by_compatible() to allow iterating over fdt nodes by compatible string. Convert various usages of off = fdt_node_offset_by_compatible(fdt, start, compat); while (off > 0) { code(); off = fdt_node_offset_by_compatible(fdt, off, compat); } and similar, to fdt_for_each_node_by_compatible(off, fdt, start, compat) code(); Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Reviewed-by: Simon Glass

net: fsl: Fix busy flag polling register

2022-01-15T16:53:16Z

NXP's mEMAC reference manual, Chapter 6.5.5 "MDIO Ethernet Management Interface usage", specifies to poll the BSY (0) bit in the CFG/STAT register to wait until a transaction has finished, not bit 31 in the data register. In the Linux kernel, this has already been fixed in commit 26eee0210ad7 ("net/fsl: fix a bug in xgmac_mdio"). This patch changes the register in the fman_mdio and fsl_ls_mdio drivers. As the MDIO_DATA_BSY define is no longer in use, this patch also removes its definition from the fsl_memac header. Signed-off-by: Markus Koch Reviewed-by: Camelia Groza

Convert CONFIG_ENV_SPI_BUS et al to Kconfig

2021-12-27T13:40:33Z

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: 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