u-boot.git/drivers/net/fm/eth.c, branch v2022.04

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

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

dm: Use access methods for dev/uclass private data

2021-01-05T19:24:40Z

Most drivers use these access methods but a few do not. Update them. In some cases the access is not permitted, so mark those with a FIXME tag for the maintainer to check. Signed-off-by: Simon Glass Acked-by: Andy Shevchenko Acked-by: Pratyush Yadav

dm: treewide: Rename dev_get_platdata() to dev_get_plat()

2020-12-13T23:51:09Z

Rename this to be consistent with the change from 'platdata'. Signed-off-by: Simon Glass

dm: treewide: Rename 'platdata' variables to just 'plat'

2020-12-13T23:51:08Z

We use 'priv' for private data but often use 'platdata' for platform data. We can't really use 'pdata' since that is ambiguous (it could mean private or platform data). Rename some of the latter variables to end with 'plat' for consistency. Signed-off-by: Simon Glass

dm: treewide: Rename auto_alloc_size members to be shorter

2020-12-13T15:00:25Z

This construct is quite long-winded. In earlier days it made some sense since auto-allocation was a strange concept. But with driver model now used pretty universally, we can shorten this to 'auto'. This reduces verbosity and makes it easier to read. Coincidentally it also ensures that every declaration is on one line, thus making dtoc's job easier. Signed-off-by: Simon Glass

treewide: convert bd_t to struct bd_info by coccinelle

2020-07-17T13:30:13Z

The Linux coding style guide (Documentation/process/coding-style.rst) clearly says: It's a **mistake** to use typedef for structures and pointers. Besides, using typedef for structures is annoying when you try to make headers self-contained. Let's say you have the following function declaration in a header: void foo(bd_t *bd); This is not self-contained since bd_t is not defined. To tell the compiler what 'bd_t' is, you need to include #include void foo(bd_t *bd); Then, the include direcective pulls in more bloat needlessly. If you use 'struct bd_info' instead, it is enough to put a forward declaration as follows: struct bd_info; void foo(struct bd_info *bd); Right, typedef'ing bd_t is a mistake. I used coccinelle to generate this commit. The semantic patch that makes this change is as follows: @@ typedef bd_t; @@ -bd_t +struct bd_info Signed-off-by: Masahiro Yamada

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq

2020-05-20T12:46:56Z

- Add DM_ETH support for lx2160aqds, ls2080aqds, ls1088aqds - QSI related fixes on ls1012a, ls2080a, ls1046a, ls1088a, ls1043a based platforms - Bug-fixes/updtaes related to ls1046afrwy, fsl-mc, msi-map property

driver: net: fm: minor fix in DM ETH support

2020-05-19T03:52:07Z

Bus callback functions for read/write/reset need to be set only for DM_ETH, moving endif a bit lower. Signed-off-by: Madalin Bucur Reviewed-by: Priyanka Jain