gpio:
- Add modepin driver
net:
- Save random mac addresses to eth variable
zynqmp gem:
- Add support for mdio bus DT description
- Add support for reset and SGMII phy configuration
- Reduce timeout for MDIO accesses
zynqmp clk:
- Fix clock handling for gem and usb
phy:
- Add zynqmp phy/serdes driver
serial:
- Add one missing compatible string
microblaze:
- Symbol alignement
- SPL fixups
- Code cleanups
zynqmp:
- Various dt changes, DP pre-reloc, gem resets, gem clocks
- Switch SOM to shared psu configuration
- Move dcache handling to firmware driver
- Workaround gmii2rgmii DT description issue
- Enable broadcasts again
- Change firmware enablement logic
- Small adjustement in firmware driver
versal:
- Support new mmc@ DT nodes
- Fix run time variable handling
- Add missing I2C_PMC ID for power domain
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCYeg7sQAKCRDKSWXLKUoM
IVhJAKCAiNx/joEeFBJ0XgThtJzFhCjdMwCfYKY9Ewz4L0n2I56lDgR3UJroct0=
=HtB+
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2022.04-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2022.04-rc1
gpio:
- Add modepin driver
net:
- Save random mac addresses to eth variable
zynqmp gem:
- Add support for mdio bus DT description
- Add support for reset and SGMII phy configuration
- Reduce timeout for MDIO accesses
zynqmp clk:
- Fix clock handling for gem and usb
phy:
- Add zynqmp phy/serdes driver
serial:
- Add one missing compatible string
microblaze:
- Symbol alignement
- SPL fixups
- Code cleanups
zynqmp:
- Various dt changes, DP pre-reloc, gem resets, gem clocks
- Switch SOM to shared psu configuration
- Move dcache handling to firmware driver
- Workaround gmii2rgmii DT description issue
- Enable broadcasts again
- Change firmware enablement logic
- Small adjustement in firmware driver
versal:
- Support new mmc@ DT nodes
- Fix run time variable handling
- Add missing I2C_PMC ID for power domain
The fastboot protocol uses per default the UDP port 5554. In some cases
it might be needed to change the used port. The fastboot utility provides
a way to specifiy an other port number to use already.
fastboot -s udp:192.168.1.76:1234 boot fastboot.img
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
If the DSA API is going to allow drivers to do things such as:
- phy_config in dsa_ops :: port_probe
- phy_startup in dsa_ops :: port_enable
then it would actually be good if the ->port_probe() method would
actually be called in all cases before the ->port_enable() is.
Currently this is true for user ports, but not true for the CPU port,
because the CPU port does not have a udevice registered for it (this is
all part of DSA's design). So the current issue is that after
phy_startup has finished for the CPU port, its phydev->speed is an
uninitialized value, because phy_config() was never called for the
priv->cpu_port_fixed_phy, and it is precisely phy_config() who copies
the speed into the phydev in the case of the fixed PHY driver.
So we need to simulate a probing event for the CPU port by manually
calling the driver's ->port_probe() method for the CPU port.
Fixes: 8a2982574854 ("net: dsa: introduce a .port_probe() method in struct dsa_ops")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
When a MAC address is randomly generated we currently only update the
appropriate data structure. For consistency and to re-align with
historic usage, it should be also saved to the appropriate environment
variable as well.
Cc: Wolfgang Denk <wd@denx.de>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
[trini: Update Kconfig, handle legacy networking case as well]
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Ramon Fried <rfried.dev@gmail.com>
Link: https://lore.kernel.org/r/1a2518e3cc19c14a41875ef64c5acc1f16edc813.1641893287.git.michal.simek@xilinx.com
set_promisc() call accepts the parameter of a bool type. Make it
clear by using true instead of 1.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The VCI string sent during bootp of U-Boot-SPL is corrupt. This is
because the byte counter is not adjusted within the bootp_extended()
function when the VCI string is added. We fix this.
Signed-off-by: Walter Stoll <walter.stoll@duagon.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the current DSA switch driver API, only the udevice of the switch
(belonging to UCLASS_DSA) is exposed, as well as an "int port" argument.
So drivers do not have access to the udevice of individual ports
(belonging to UCLASS_ETH), one of the reasons being that not all ports
have an associated UCLASS_ETH udevice.
However, all DSA ports have an OF node, and in some cases the driver
needs a handle to it, for all ports including the CPU port. Example: the
following Linux per-port device tree property:
managed = "in-band-status";
states whether a port should operate with clause 37 in-band autoneg
enabled or not.
This patch exposes a function which can be called by individual drivers
as needed.
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 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 <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
dm_mdio_post_probe used to be vulnerable after truncation, but has been
patched by commit 398e7512d8 ("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 <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
"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 <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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: fc054d563b ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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 <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Michael Walle <michael@walle.cc>
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 <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Michael Walle <michael@walle.cc>
DM DSA uses "err" for error code values, so use this consistently.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Michael Walle <michael@walle.cc>
The code under drivers/net is related to ethernet networking drivers, in
some fashion or another. Drop these from the top-level Makefile and
also move the phy rule into drivers/net/Makefile which is where it
belongs. Make the new rule for drivers/net check for the build-stage
relevant ETH symbol.
Fix up some Kconfig dependencies while we're here to mirror how the
Makefile logic now works.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Introduce ETH, Kconfig dependency changes, am43xx fix]
Signed-off-by: Tom Rini <trini@konsulko.com>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Define LOG_CATEGORY to allow filtering with log command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
If ports have their own unique MAC addrs and master has a set_promisc
function, call it so that packets will be received for ports.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
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 fc054d563b ("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>
TFTP transfer size can be used to re-size the TFTP progress bar on
single line based on the server reported file size. The support for
this has been around from 2019, but it was never converted to proper
Kconfig.
While adding this new Kconfig, enable it by default for OMAP2+ and K3
devices also.
Signed-off-by: Tero Kristo <kristo@kernel.org>
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 db40c1aa1c ("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 eef0b8a930 ("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: fc054d563b ("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: fc054d563b ("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: cc6b87ecaa ("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>
DSA stands for Distributed Switch Architecture and it covers switches that
are connected to the CPU through an Ethernet link and generally use frame
tags to pass information about the source/destination ports to/from CPU.
Front panel ports are presented as regular ethernet devices in U-Boot and
they are expected to support the typical networking commands.
DSA switches may be cascaded, DSA class code does not currently support
this.
Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This function may be used in SPL where devicetree is not available.
Use the correct macro so that the function does not try to read it.
Signed-off-by: Simon Glass <sjg@chromium.org>
This reverts commit 1231184caa.
While the change is fine in theory, a number of tests need to be updated
to match.
Signed-off-by: Tom Rini <trini@konsulko.com>
dev_read_alias_seq() used uc_drv->name compared to alias
stem string, Ethernet's alias stem uses "ethernet", which
does not match the eth-uclass driver name "eth", can not
get the correct index of ethernet alias namer. So it seems
change uclass driver name to match the alias stem is a more
reasonable way.
Signed-off-by: David Wu <david.wu@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When calling srand_mac we use a weak seed dependent on the
mac address. If present, use a RNG device instead to incerase entropy.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Torsten Duwe <duwe@suse.de>
Fix typo which would cause a build error.
Fixes: 3eaac6307d ("net: introduce packet capture support")
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
When the tftp server did not send any OACK, the tftp_next_ack variable
was not set to the correct value . As the server was transmitting
blocks we generated a lot of 'Received unexpected block: $n, expected
$n+1' error messages. Depending on the timeout setting the transfer
could still complete though.
Signed-off-by: Harm Berntsen <harm.berntsen@nedap.com>
CC: Ramon Fried <rfried.dev@gmail.com>
Reviewed-By: Ramon Fried <rfried.dev@gmail.com>
While doing DHCP the interface IP is set to 0.0.0.0. This causes the
check in net.c on dst_ip to be effectively skipped, and all IP datagrams
are accepted up the IP stack. In the case of an ICMP_ECHO_REQUEST for the
matching MAC address (regardless of destination IP), the result is that
an ICMP_ECHO_REPLY is sent. The source address of the ICMP_ECHO_REPLY is
0.0.0.0, which is an illegal source address.
This can happen in common practice with the following sequence:
DHCP (U-Boot or OS) acquires IP address 10.0.0.1
System reboots
U-Boot starts DHCP and send DHCP DISCOVER
DHCP server decides to OFFER 10.0.0.1 again
(perhaps because of existing lease or manual configuration)
DHCP server tries to PING 10.0.0.1 to see if anyone is squatting on it
DHCP server still has our MAC address in its ARP table for 10.0.0.1
U-Boot receives PING, and responds with an illegal source address
This may further result in a the DHCP server seeing the response as
confirmation that someone is squatting on 10.0.0.1, and picking a
new IP address from the pool to try again
Signed-off-by: David Rivshin <drivshin@allworx.com>
Running the start() handler twice without a stop() inbetween completely
breaks communication for some ethernet drivers like fec_mxc.
eth_halt() is called before each eth_init(). Due to the switch to
eth_is_active() in commit 68acb51f44 ("net: Only call halt on a driver
that has been init'ed"), this is not sufficient anymore when netconsole
is active: eth_init_state_only()/eth_halt_state_only() manipulate the
state check that is performed by eth_is_active() without actually
calling into the driver.
The issue can be triggered by starting a network operation (e.g. ping or
tftp) while netconsole is active.
Add an additional "running" flag that reflects the actual state of the
driver and use it to ensure that eth_halt() actually stops the device as
it is supposed to.
Fixes: 68acb51f44 ("net: Only call halt on a driver that has been init'ed")
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
