Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
the linux tree:

$ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
0
$ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
633

In u-boot device trees both prefixes are used. Until recently the only
user of the ethernet alias was the sandbox test device tree. This
changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet
switches"). There, the MAC addresses are inherited based on the devices
sequence IDs which is in turn given by the device tree.

Before there are more users in u-boot and both worlds will differ even
more, rename the alias prefix to "ethernet" to match the linux ones.
Also adapt the test cases and rename any old aliases in the u-boot
device trees.

Cc: David Wu <david.wu@rock-chips.com>
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

If the environment variable "ethact" is not set, the first device in the
uclass is returned. This depends on the probing order of the ethernet
devices. Moreover it is not not configurable at all.

Try to return the ethernet device with sequence id 0 first which then
can be configured by the aliases in a device tree. Fall back to the old
mechanism in case of an error.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>

On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
as const struct device_node *np, while on the flat DT systems it
is defined as a long of_offset into gd->fdt_blob.

It is desirable that the fixed PHY driver uses the higher-level
ofnode abstraction instead of parsing gd->fdt_blob directly,
because that enables it to work on live OF systems.

The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c10 ("drivers/net/phy: add fixed-phy /
fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already
mismatched leading to a potential truncation (flat OF offset was
supposed to be a long and not an int), we really cannot extend this
hack any longer, because there's no way an int will hold the other
representation of ofnode, the struct device_node *np.

So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in
commit eef0b8a930d1 ("net: phy: add ofnode node to struct phy_device").
This will populate phydev->node for the fixed PHY.

Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver. The new function
will be called at phy_config() time.

I do believe I've converted all the possible call paths for creating
a PHY with PHY_FIXED_ID, so there is really no reason to maintain
compatibility with the old logic of retrieving a flat OF tree offset
from phydev->addr. We just pass 0 to phydev->addr now.

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>
Message-Id: <20210216224804.3355044-2-olteanv@gmail.com>
[bmeng: keep fixedphy_probe(); update mdio-uclass.c to handle fixed phy]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Switch to use the ofnode_phy_is_fixed_link() API which can support
both the new and old DT bindings.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Because we probe the master ourselves (and fail if there is no master),
it is not possible that we don't have a master device.

There is one catch though: device removal. We don't support that. It
wasn't supported neither before this patch. Because the master device
was only set in .pre_probe(), if a device was removed master_dev was a
dangling pointer and transmitting a frame cause a panic. I don't see a
good solution without having some sort of notify machanism when a
udevice is removed.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc> [DSA unit tests]
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Because the uclass has the "*_auto" properties set, the driver model
will take care of allocating the private structures for us and they
can't be NULL. Drop the checks.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

DSA needs to have the master device probed first for MAC inheritance.
Until now, it only works by chance because the only user (LS1028A SoC)
will probe the master device first. The probe order is given by the PCI
device ordering, thus it works because the master device has a "smaller"
BDF then the switch device.

Explicitly probe the master device in dsa_port_probe().

Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

It doesn't make sense to have DSA without a master port. Error out early
if there is no master port.

Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

When trying to port our mpc8309-based board to DM_ETH, on top of
Heiko's patches, I found that nothing in mdio-uclass.c seems to
support the use of a fixed-link subnode of the ethernet DT node. That
is, the ethernet node looks like

		enet0: ethernet@2000 {
			device_type = "network";
			compatible = "ucc_geth";
			...
			fixed-link {
				reg = <0xffffffff>;
				speed = <100>;
				full-duplex;
			};

but the current code expects there to be phy-handle property. Adding
that, i.e.

			phy-handle = <&enet0phy>;
			enet0phy: fixed-link {

just makes the code break a few lines later since a fixed-link node
doesn't have a reg property. Ignoring the dtc complaint and adding a
dummy reg property, we of course hit "can't find MDIO bus for node
ethernet@2000" since indeed, the parent node of the phy node does not
represent an MDIO bus. So that's obviously the wrong path.

Now, in linux, it seems that the fixed link case is treated specially;
in the of_phy_get_and_connect() which roughly corresponds to
dm_eth_connect_phy_handle() we have

    if (of_phy_is_fixed_link(np)) {
        ret = of_phy_register_fixed_link(np);
        ...
    } else {
        phy_np = of_parse_phandle(np, "phy-handle", 0);
	...
    }

    phy = of_phy_connect(dev, phy_np, hndlr, 0, iface);

And U-Boot's phy_connect() does have support for fixed-link
subnodes. Calling phy_connect() directly with NULL bus and a dummy
address does seem to make the ethernet work.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Heiko Schocher <hs@denx.de>

in tftpboot, if ack was already sent previously for this
packet, don't send again.

Fixes: cc6b87ecaa96 ("net: tftp: Add client support for RFC 7440")

Reported-by: Suneel Garapati <suneelglinux@gmail.com>
Signed-off-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Suneel Garapati <suneelglinux@gmail.com>
Tested-by: Oliver Graute <oliver.graute@kococonnector.com>