summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2021-12-13net: ravb: Support multiple clocksAdam Ford1-5/+5
The RZ/G2 series uses an external clock as a reference to the AVB. If this clock is controlled by an external programmable clock, it must be requested by the consumer or it will not turn on. In order to do this, update the driver to use bulk enable and disable functions to enable clocks for boards with multiple clocks. Signed-off-by: Adam Ford <aford173@gmail.com>
2021-12-03Merge https://source.denx.de/u-boot/custodians/u-boot-riscvTom Rini1-11/+7
2021-12-02net: macb: Remove Microchip compatible stringPadmarao Begari1-11/+7
Remove the microchip compatible string and default compatible "cdns,macb" support both 32-bit and 64-bit DMA access. Signed-off-by: Padmarao Begari <padmarao.begari@microchip.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2021-12-02net: dwc_eth_qos: Enable clock in probeMarek Vasut1-11/+11
Enable DWC IP clock in driver probe, so the MII access is possible even outside of active network transfers. This is particularly useful when using 'mii' or 'mdio' commands to explore PHY state, neither of which works with DWMAC currently due to the disabled clock. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Joe Hershberger <joe.hershberger@ni.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Ramon Fried <rfried.dev@gmail.com> Cc: Stephen Warren <swarren@nvidia.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-12-02net: eth-phy: Handle gpio_request_by_name() return valueMarek Vasut1-1/+1
The gpio_request_by_name() returns zero in case of success, however the conditional return value check in gpio_request_by_name() checks only for (ret != -ENOENT) and if the condition is true, returns ret outright. This leads to a situation where successful gpio_request_by_name() return leads to immediate successful eth_phy_of_to_plat() return as well, and to skipped parsing of "reset-assert-us" and "reset-deassert-us", so the PHY driver operates with valid reset GPIO, but with assert/deassert times set to default, which is 0, instead of the values from DT. This breaks PHY reset. Fix this by checking if return value is non-zero and then for this one single allowed non-zero return value, -ENOENT. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-11-16Merge tag 'xilinx-for-v2022.01-rc3' of ↵Tom Rini1-0/+2
https://source.denx.de/u-boot/custodians/u-boot-microblaze Xilinx changes for v2022.01-rc3 sdhci: - Fix emmc mini case with missing firmware interface zynqmp: - Restore JTAG interface if required - Allow overriding board name - Add support for DLC21 - Fix one fallthrought statement description - Use config macro instead of name duplication - Save multiboot to variable firmware: - Handle ipi_req errors better - Use local buffer in case user doesn't need it instead of NULL/0 location spi: - gqsi: Fix write issue at low frequencies net: - gem: Disable broadcasts
2021-11-12Convert CONFIG_MACB to KconfigTom Rini1-1/+0
This converts the following to Kconfig: CONFIG_MACB Signed-off-by: Tom Rini <trini@konsulko.com>
2021-11-09configs: fsl: migrate FMAN/QE specific defines to KconfigRajesh Bhagat1-0/+10
Use moveconfig.py script to convert CONFIG_SYS_FMAN_FW_ADDR, CONFIG_SYS_QE_FW_ADDR and CONFIG_SYS_QE_FMAN_FW_LENGTH to Kconfig and move these entries to defconfigs. Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com> [Rebased] Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-11-09drivers: net: fsl-mc: add a command which dumps the MC logCosmin-Florin Aluchenesei1-1/+88
Extended fsl_mc command adding an extra option dump_log Signed-off-by: Cosmin-Florin Aluchenesei <aluchenesei.cosmin-florin@nxp.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-10-21net: gem: Disable broadcast settingMichal Simek1-0/+2
There is no need for GEM to accepts broadcast packets because they are not handled by u-boot anyway. That's why use HW IP feature and don't waste time on these packats which will be dropped anyway. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Link: https://lore.kernel.org/r/0e236c3a6514a2a633ef3a5b71a967c46f7fbae7.1634303007.git.michal.simek@xilinx.com
2021-10-20net: macb: Fix -Wint-to-pointer-cast warningsBin Meng1-8/+3
The following warning is seen in macb.c in a 32-bit build: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Change to use dev_read_addr_index_ptr(), or cast with uintptr_t. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-10-11sunxi: Clean up inclusions of asm/arch/gpio.hSamuel Holland1-4/+1
As part of migrating to DM_GPIO and DM_PINCTRL, eventually we will remove the asm/arch/gpio.h header. In preparation, clean up the various files that include it. Some files did not contain any GPIO code at all, so this header was completely unused. A few files contained only legacy platform-specific GPIO code for setting up pin muxes. They were left unchanged, as that code will be completely removed by the DM_PINCTRL migration. The remaining files contain some combination of DM_GPIO and legacy GPIO code. For those, switch to including asm/gpio.h (if it wasn't included already). Right now, this header provides both sets of functions, because ARCH_SUNXI selects GPIO_EXTRA_HEADER. This will still be the right header to include once the DM_GPIO migration is complete and GPIO_EXTRA_HEADER is no longer needed. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-10-02arm: Remove zmx25 board and ARCH_MX25Tom Rini2-3/+3
This board has not been converted to CONFIG_DM by the deadline. Remove it. As this is the last ARCH_MX25 platform, remove those references as well. Cc: Matthias Weisser <weisserm@arcor.de> Cc: Stefano Babic <sbabic@denx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-30WS cleanup: remove SPACE(s) followed by TABWolfgang Denk5-7/+7
Signed-off-by: Wolfgang Denk <wd@denx.de>
2021-09-30WS cleanup: remove trailing white spaceWolfgang Denk1-1/+1
Signed-off-by: Wolfgang Denk <wd@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-09-30WS cleanup: remove excessive empty linesWolfgang Denk1-4/+0
Signed-off-by: Wolfgang Denk <wd@denx.de>
2021-09-30WS cleanup: remove trailing empty linesWolfgang Denk7-7/+0
Signed-off-by: Wolfgang Denk <wd@denx.de>
2021-09-29Merge branch 'network_master' of ↵Tom Rini26-73/+83
https://source.denx.de/u-boot/custodians/u-boot-net into next - Fix some non-NULL terminated strings in the networking subsystem - net: tsec: Mark tsec_get_interface as __maybe_unused
2021-09-28net: dsa: felix: check return code of mdio_alloc and mdio_registerVladimir Oltean1-1/+9
These functions can return errors, it's best to catch them and trigger the driver unwind code path. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: davinci_emac: ensure mdiodev->name is NULL terminated after ↵Vladimir Oltean1-1/+1
MDIO_NAME_LEN truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: smc911x: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: sh_eth: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: mvgbe: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: dsa: felix: ensure mii_bus->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-2/+2
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: mpc8xx_fec: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: macb: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-2/+2
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: lpc32xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: ftmac110: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: mcdmafec: ensure bus->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: enetc: ensure imdio.name is NULL terminated after MDIO_NAME_LEN truncationVladimir Oltean1-1/+1
strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: ep93xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: eepro100: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: bcm-sf2: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: at91_emac: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean1-1/+1
truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: armada100_fec: ensure mdiodev->name is NULL terminated after ↵Vladimir Oltean1-1/+1
MDIO_NAME_LEN truncation strncpy() simply bails out when copying a source string whose size exceeds the destination string size, potentially leaving the destination string unterminated. One possible way to address is to pass MDIO_NAME_LEN - 1 and a previously zero-initialized destination string, but this is more difficult to maintain. The chosen alternative is to use strlcpy(), which properly limits the copy len in the (srclen >= size) case to "size - 1", and which is also more efficient than the strncpy() byte-by-byte implementation by using memcpy. The destination string returned by strlcpy() is always NULL terminated. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: tsec: read the phy-mode property as fallback to phy-connection-typeVladimir Oltean1-0/+2
The two should be equivalent, but at the moment some platforms (ls1021a-tsn.dts) use phy-mode only, which is not parsed. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: tsec: only call tsec_get_interface as fallback to DT-specified PHY modeVladimir Oltean1-6/+3
Currently the init_phy function may overwrite the priv->interface property, since it calls tsec_get_interface which tries to determine it dynamically based on default register values in ECNTRL. Let's do that only if phy-connection-type happens to not be defined in the device tree. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: dsa: felix: remove "xgmii" phy-modeVladimir Oltean1-1/+0
The felix driver runs only on NXP LS1028A, which most definitely does not support the parallel 10G interface, just USXGMII, and that only up to 2.5Gbps (toned down from 10 Gbps via symbol replication). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: enetc: remove support for "xgmii" phy-modeVladimir Oltean1-2/+0
The enetc driver runs only on NXP LS1028A, which most definitely does not support the parallel 10G interface, just USXGMII, and that only up to 2.5Gbps (toned down from 10 Gbps via symbol replication). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"Vladimir Oltean9-18/+18
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 <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: replace the "xfi" phy-mode with "10gbase-r"Vladimir Oltean5-13/+13
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 <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: phy: genphy_init can be staticVladimir Oltean1-1/+1
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 <vladimir.oltean@nxp.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: update NXP copyright textVladimir Oltean2-2/+2
NXP Legal insists that the following are not fine: - Saying "NXP Semiconductors" instead of "NXP", since the company's registered name is "NXP" - Putting a "(c)" sign in the copyright string - Putting a comma in the copyright string The only accepted copyright string format is "Copyright <year-range> NXP". This patch changes the copyright headers in the networking files that were sent by me, or derived from code sent by me. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-28net: dsa: felix: propagate the error code from phy_startup()Vladimir Oltean1-3/+1
Make sure that the link status returned by phy_startup() is propagated to the .start() method of struct eth_ops. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Tested-by: Michael Walle <michael@walle.cc>
2021-09-28net: dsa: felix: call phy_config at .port_probe() timeVladimir Oltean1-7/+15
It is an unfortunate reality that some PHY settings done by U-Boot persist even after the PHY is reset and taken over by Linux, and even more unfortunate that Linux has come to depend on things being set in a certain way. For example, on the NXP LS1028A-RDB, the felix switch ports are connected to a VSC8514 QSGMII PHY. Between the switch port PCS and the PHY, the U-Boot drivers enable in-band auto-negotiation which makes the copper-side negotiated speed and duplex be transmitted from the PHY to the MAC automatically. The PHY driver portion that does this is in vsc8514_config(): /* Enable Serdes Auto-negotiation */ phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, PHY_EXT_PAGE_ACCESS_EXTENDED3); val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON); val = val | MIIM_VSC8574_MAC_SERDES_ANEG; phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val); The point is that in-band autoneg should be turned on in both the PHY and the MAC, or off in both the PHY and the MAC, otherwise the QSGMII link will be broken. And because phy_config() is currently called at .port_enable() time, the result is that ports on which traffic has been sent in U-Boot will have in-band autoneg enabled, and the rest won't. It can be argued that the Linux kernel should not assume one way or another and just reinitialize everything according to what it expects, and that is completely fair. In fact, I've already started an attempt to remove this dependency, although admittedly I am making slow progress at it: https://patchwork.kernel.org/project/netdevbpf/cover/20210212172341.3489046-1-olteanv@gmail.com/ Nonetheless, the sad reality is that NXP also has, apart from kernel drivers, some user space networking (DPDK), and for some reason, the expectation there is that somebody else initializes the PHYs. The kernel can't do it because the device ownership doesn't belong to the kernel, so what remains is for the bootloader to do it (especially since other drivers generally call phy_config() at probe time). This is a really weak guarantee that might break at any time, but apparently that is enough for some. Since initializing the ports and PHYs at probe time does not break anything, we can just do that. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Tested-by: Michael Walle <michael@walle.cc>
2021-09-28net: dsa: felix: felix_init() can be staticVladimir Oltean1-1/+1
No one is calling this function from outside felix_switch.c. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Tested-by: Michael Walle <michael@walle.cc>
2021-09-28net: tsec: Mark tsec_get_interface as __maybe_unusedRamon Fried1-1/+1
Non DM builds fail with the following error: drivers/net/tsec.c:641:24: error: 'tsec_get_interface' defined but not used [-Werror=unused-function] 641 | static phy_interface_t tsec_get_interface(struct tsec_private *priv) Fix that. Signed-off-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-21net: remove unused CONFIG_DRIVER_AT91EMAC_*Eugen Hristev2-520/+0
AT91EMAC driver is unused, thus removing. Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
2021-09-16Merge tag 'v2021.10-rc4' into nextTom Rini3-17/+13
Prepare v2021.10-rc4 Signed-off-by: Tom Rini <trini@konsulko.com> # gpg: Signature made Tue 14 Sep 2021 06:58:32 PM EDT # gpg: using RSA key 1A3C7F70E08FAB1707809BBF147C39FF9634B72C # gpg: Good signature from "Thomas Rini <trini@konsulko.com>" [ultimate] # Conflicts: # board/Arcturus/ucp1020/spl.c # cmd/mvebu/Kconfig # common/Kconfig.boot # common/image-fit.c # configs/UCP1020_defconfig # configs/sifive_unmatched_defconfig # drivers/pci/Kconfig # include/configs/UCP1020.h # include/configs/sifive-unmatched.h # lib/Makefile # scripts/config_whitelist.txt
2021-09-14pci: Drop DM_PCISimon Glass2-5/+3
This option has not effect now. Drop it, using PCI instead where needed. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-02 18:13:33 +0300