Skip to content
Snippets Groups Projects
  1. Jan 21, 2022
  2. Jan 19, 2022
  3. Jan 15, 2022
    • Christian Gmeiner's avatar
      net: fastboot: make UDP port net: configurable · 046bf8d4
      Christian Gmeiner authored
      
      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: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      Reviewed-by: default avatarHeiko Schocher <hs@denx.de>
      Reviewed-by: default avatarRamon Fried <rfried.dev@gmail.com>
      046bf8d4
    • Vladimir Oltean's avatar
      net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY · 0fa4448d
      Vladimir Oltean authored
      
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarRamon Fried <rfried.dev@gmail.com>
      0fa4448d
  4. Jan 11, 2022
  5. Nov 23, 2021
  6. Sep 30, 2021
  7. Sep 28, 2021
  8. Sep 17, 2021
  9. Sep 04, 2021
    • Simon Glass's avatar
      net: Move network rules to drivers/net · 9f664920
      Simon Glass authored
      
      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: default avatarSimon Glass <sjg@chromium.org>
      [trini: Introduce ETH, Kconfig dependency changes, am43xx fix]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      9f664920
  10. Aug 31, 2021
  11. Aug 02, 2021
  12. Jul 22, 2021
  13. Jul 10, 2021
  14. Jun 18, 2021
    • Michael Walle's avatar
      net: use the same alias stem for ethernet as linux · 82a3c9ef
      Michael Walle authored
      
      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 fc054d56 ("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: default avatarMichael Walle <michael@walle.cc>
      Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      82a3c9ef
    • Michael Walle's avatar
      net: use a more deterministic approach to get the active ethernet device · 6e424b4a
      Michael Walle authored
      
      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: default avatarMichael Walle <michael@walle.cc>
      Reviewed-by: default avatarRamon Fried <rfried.dev@gmail.com>
      6e424b4a
  15. Jun 09, 2021
    • Tero Kristo's avatar
      net: convert TFTP_TSIZE to proper Kconfig option · 2509493c
      Tero Kristo authored
      
      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: default avatarTero Kristo <kristo@kernel.org>
      2509493c
  16. Apr 15, 2021
    • Vladimir Oltean's avatar
      net: phy: fixed: Be compatible with live OF tree · f27bc8af
      Vladimir Oltean authored
      
      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 db40c1aa ("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 eef0b8a9 ("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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Tested-by: default avatarBin 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: default avatarBin Meng <bmeng.cn@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarPriyanka Jain <priyanka.jain@nxp.com>
      f27bc8af
    • Bin Meng's avatar
      dm: mdio: Use ofnode_phy_is_fixed_link() API · 33aad0b0
      Bin Meng authored
      
      Switch to use the ofnode_phy_is_fixed_link() API which can support
      both the new and old DT bindings.
      
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Reviewed-by: default avatarRamon Fried <rfried.dev@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarPriyanka Jain <priyanka.jain@nxp.com>
      33aad0b0
  17. Mar 05, 2021
  18. Feb 22, 2021
    • Rasmus Villemoes's avatar
      mdio-uclass.c: support fixed-link subnodes · bdf31927
      Rasmus Villemoes authored
      
      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: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: default avatarHeiko Schocher <hs@denx.de>
      bdf31927
  19. Feb 18, 2021
  20. Feb 16, 2021
  21. Feb 02, 2021
    • Simon Glass's avatar
      common: Drop asm/global_data.h from common header · 401d1c4f
      Simon Glass authored
      
      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: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      401d1c4f
  22. Jan 27, 2021
Loading