summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-09-28Merge branch '2021-09-25-TI-platform-updates' into nextTom Rini
- Start moving some TI board docs to rST - Assorted TI-specific Kconfig migrations and namespace cleanups. This also allows for some code cleanups.
2021-09-28Merge tag '20210928-for-next' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-i2c into next i2c changes for 20210928-for-next - i2c: rcar_i2c: Enable configuring SCL rise and fall times - i2c: mvtwsi: Add support for DM clocks and resets - mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface
2021-09-28Merge branch '2021-09-28-regression-fixes'Tom Rini
- Reintroduce creating internally the "nor%d" style names, in order to fix some use U-Boot use-cases involving the "mtd" command. - Fix a regression over the default SPI bus mode shown by having the compiled default actually start being used. The correct default here is 0. - Fix ethernet on imx7d-sdb - Fix a regression with MTD NAND devices when OF_LIVE is enabled
2021-09-28imx: imx7d-sdb: fix ethernet, sync .dts with linuxRasmus Villemoes
Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0 (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync device tree with v5.5-rc1", but in the linux tree, these gpios have always been GPIO_ACTIVE_HIGH ever since this node was introduced around v4.13 (linux commit 184f39b5). I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work around the behaviour of the soft-spi driver back then, which effectively defaulted to spi-mode 3 and not 0. That was arguably a bug in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add support for all spi modes with soft spi), but that commit then broke ethernet on this board. Fix it by setting the gpios as active high, which as a bonus actually brings us in sync with the .dts in the linux source tree. Without this, one gets Net: Could not get PHY for FEC0: addr 0 No ethernet found. With this, ethernet (at least ping and tftp) works as expected from the U-Boot shell. Cc: Fabio Estevam <[email protected]> Cc: Joris Offouga <[email protected]> Cc: "Christian Bräuner Sørensen" <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]>
2021-09-28mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interfacePatrice Chotard
nand_dt_init() is still using fdtdec_xx() interface. If OF_LIVE flag is enabled, dt property can't be get anymore. Updating all fdtdec_xx() interface to ofnode_xx() to solve this issue. For doing this, node parameter type must be ofnode. First idea was to convert "node" parameter to ofnode type inside nand_dt_init() using offset_to_ofnode(node). But offset_to_ofnode() is not bijective, in case OF_LIVE flag is enabled, it performs an assert(). So, this leads to update nand_chip struct flash_node field from int to ofnode and to update all nand_dt_init() callers. Signed-off-by: Patrice Chotard <[email protected]>
2021-09-28mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0Marek Vasut
Before e2e95e5e254 ("spi: Update speed/mode on change") most systems silently defaulted to SF bus mode 0. Now the mode is always updated, which causes breakage. It seems most SF which are used as boot media operate in bus mode 0, so switch that as the default. This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked as those might need mode 3. Signed-off-by: Marek Vasut <[email protected]> Cc: Aleksandar Gerasimovski <[email protected]> Cc: Andreas Biessmann <[email protected]> Cc: Eugen Hristev <[email protected]> Cc: Michal Simek <[email protected]> Cc: Patrice Chotard <[email protected]> Cc: Patrick Delaunay <[email protected]> Cc: Peng Fan <[email protected]> Cc: Siew Chin Lim <[email protected]> Cc: Tom Rini <[email protected]> Cc: Valentin Longchamp <[email protected]> Cc: Vignesh Raghavendra <[email protected]>
2021-09-28mtd: spi: nor: force mtd name to "nor%d"Patrick Delaunay
Force the mtd name of spi-nor to "nor" + the driver sequence number: "nor0", "nor1"... beginning after the existing nor devices. This patch is coherent with existing "nand" and "spi-nand" mtd device names. When CFI MTD NOR device are supported, the spi-nor index is chosen after the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS. When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config is replaced by to cfi_flash_num_flash_banks in the include file mtd/cfi_flash.h. This generic name "nor%d" can be use to identify the mtd spi-nor device without knowing the real device name or the DT path of the device, used with API get_mtd_device_nm() and is used in mtdparts command. This patch also avoids issue when the same NOR device is present 2 times, for example on STM32MP15F-EV1: STM32MP> mtd list SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \ total 64 MiB List of MTD devices: * nand0 - type: NAND flash - block size: 0x40000 bytes - min I/O: 0x1000 bytes - OOB size: 224 bytes - OOB available: 118 bytes - ECC strength: 8 bits - ECC step size: 512 bytes - bitflip threshold: 6 bits - 0x000000000000-0x000040000000 : "nand0" * mx66l51235l - device: mx66l51235l@0 - parent: spi@58003000 - driver: jedec_spi_nor - path: /soc/spi@58003000/mx66l51235l@0 - type: NOR flash - block size: 0x10000 bytes - min I/O: 0x1 bytes - 0x000000000000-0x000004000000 : "mx66l51235l" * mx66l51235l - device: mx66l51235l@1 - parent: spi@58003000 - driver: jedec_spi_nor - path: /soc/spi@58003000/mx66l51235l@1 - type: NOR flash - block size: 0x10000 bytes - min I/O: 0x1 bytes - 0x000000000000-0x000004000000 : "mx66l51235l" The same mtd name "mx66l51235l" identify the 2 instances mx66l51235l@0 and mx66l51235l@1. This patch fixes a ST32CubeProgrammer / stm32prog command issue with nor0 target on STM32MP157C-EV1 board introduced by commit b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is enabled"). Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is enabled") Signed-off-by: Patrick Delaunay <[email protected]> [trini: Add <dm/device.h> to <mtd.h> for DM_MAX_SEQ_STR] Signed-off-by: Tom Rini <[email protected]>
2021-09-28scripts: ensure the cocci script for miiphy_register does not leak the MDIO busVladimir Oltean
When mdio_register fails, mdio_free should be called on the mdiodev that was previously allocated with mdio_alloc. Signed-off-by: Vladimir Oltean <[email protected]>
2021-09-28arch: powerpc: mpc85xx: free MDIO bus if mdio_register failsVladimir Oltean
If mdio_register fails, it is nice to not leave behind dangling allocated memory. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: ensure port names are NULL-terminated after DSA_PORT_NAME_LENGTH ↵Vladimir Oltean
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 DSA_PORT_NAME_LENGTH - 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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: felix: check return code of mdio_alloc and mdio_registerVladimir Oltean
These functions can return errors, it's best to catch them and trigger the driver unwind code path. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28scripts: ensure the cocci script for miiphy_register does not leave ↵Vladimir Oltean
NULL-unterminated strings 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 <[email protected]>
2021-09-28net: mdio-uclass: rewrite dm_mdio_post_probe using strlcpyVladimir Oltean
dm_mdio_post_probe used to be vulnerable after truncation, but has been patched by commit 398e7512d8d7 ("net: Fix Covarity Defect 244093"). Nonetheless, we can use strlcpy like the rest of the code base now, which yields the same result. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: qe: uec: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: davinci_emac: ensure mdiodev->name is NULL terminated after ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: smc911x: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: sh_eth: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: mvgbe: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: felix: ensure mii_bus->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: mpc8xx_fec: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: macb: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: lpc32xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: ftmac110: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: mcdmafec: ensure bus->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: enetc: ensure imdio.name is NULL terminated after MDIO_NAME_LEN truncationVladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: ep93xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: eepro100: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: bcm-sf2: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: at91_emac: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: armada100_fec: ensure mdiodev->name is NULL terminated after ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28board: gdsys: a38x: ensure mdiodev->name is NULL terminated after ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28arch: powerpc: mpc85xx: ensure mdiodev->name is NULL terminated after ↵Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: tsec: read the phy-mode property as fallback to phy-connection-typeVladimir Oltean
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 <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: tsec: only call tsec_get_interface as fallback to DT-specified PHY modeVladimir Oltean
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 <[email protected]> Reviewed-by: Bin Meng <[email protected]> Tested-by: Bin Meng <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: felix: remove "xgmii" phy-modeVladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: enetc: remove support for "xgmii" phy-modeVladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"Vladimir Oltean
After the discussion here: https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/ which resulted in this patch: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/ and many other discussions before it, notably: https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/ 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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: replace the "xfi" phy-mode with "10gbase-r"Vladimir Oltean
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/[email protected]/) 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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: phy: genphy_init can be staticVladimir Oltean
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 <[email protected]> Reviewed-by: Bin Meng <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: remove unused variablesVladimir Oltean
"dev" and "dsa_pdata" are unused inside dsa_port_of_to_pdata. "dsa_priv" is unused inside dsa_port_probe. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: pass CPU port fixed PHY to .port_disableVladimir Oltean
While adding the logic for DSA to register a fixed-link PHY for the CPU port, I forgot to pass it to the .port_disable method too, just .port_enable. Bug had no impact for felix_switch.c, due to the phy argument not being used, but ksz9477.c does use it => NULL pointer dereference. Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: update NXP copyright textVladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]>
2021-09-28net: dsa: felix: propagate the error code from phy_startup()Vladimir Oltean
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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]> Tested-by: Michael Walle <[email protected]>
2021-09-28net: dsa: felix: call phy_config at .port_probe() timeVladimir Oltean
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/[email protected]/ 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 <[email protected]> Reviewed-by: Ramon Fried <[email protected]> Tested-by: Michael Walle <[email protected]>
2021-09-28net: dsa: introduce a .port_probe() method in struct dsa_opsVladimir Oltean
Some drivers might want to execute code for each port at probe time, as opposed to executing code just-in-time for the port selected for networking. To cater to that use case, introduce a .port_probe() callback method into the DSA switch operations which is called for each available port, at the end of dsa_port_probe(). Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]> Tested-by: Michael Walle <[email protected]>
2021-09-28net: dsa: refactor the code to set the port MAC address into a dedicated ↵Vladimir Oltean
function This snippet of code has a bothering "if (...) return 0" in it which assumes it is the last piece of code running in dsa_port_probe(). This makes it difficult to add further code at the end of dsa_port_probe() which does not depend on MAC address stuff. So move the code to a dedicated function which returns void and let the code flow through. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]> Tested-by: Michael Walle <[email protected]>
2021-09-28net: dsa: use "err" instead of "ret" in dsa_port_probeVladimir Oltean
DM DSA uses "err" for error code values, so use this consistently. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]> Tested-by: Michael Walle <[email protected]>
2021-09-28net: dsa: felix: felix_init() can be staticVladimir Oltean
No one is calling this function from outside felix_switch.c. Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ramon Fried <[email protected]> Tested-by: Michael Walle <[email protected]>
2021-09-28net: tsec: Mark tsec_get_interface as __maybe_unusedRamon Fried
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 <[email protected]>
2021-09-28Prepare v2021.10-rc5Tom Rini
Signed-off-by: Tom Rini <[email protected]>
generated by cgit v1.3.1 (git 2.54.0) at 2026-09-02 12:12:30 +0000