This function is also available as ofnode_is_enabled(), so use that instead. Signed-off-by: Simon Glass <sjg@chromium.org>
Add a mask parameter to control the lookup of the PCI region from which the mapping can be made. Signed-off-by: Andrew Scull <ascull@google.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Evolve dm_pci_map_bar() to include an offset and length parameter. These allow a portion of the memory to be mapped and range checks to be applied. Passing both the offset and length as zero results in the previous behaviour and this is used to migrate the previous callers. Signed-off-by: Andrew Scull <ascull@google.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It turns out that in custom designs if the system is reset multiple times in conjunction with a slight increase in external temperature, the felix switch starts to behave in a strange way: packets are no longer received on the ENECT interface connected to the L2switch internal port (the TX side of internal port stops working or the packets do not reach there. It is not very clear where the packets remain blocked. None of the counters points to a disruption in the L2switch) The issue is not reproducible on NXP reference designs. It was observed that by adding the switch core reset, the problem goes aways, even if intensive testing in temperature chambers is applied. The current patch performs soft reset on the switch core to ensure proper operation of the L2switch. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Instead of trying to guess which operating modes need in-band negotiation to be active and which ones don't, parse the available information from the device tree. That will be correct in the cases we can already guess, and more. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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>
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>
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>
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>
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>