1. 06 Feb, 2020 1 commit
  2. 29 Jan, 2020 1 commit
  3. 27 Jan, 2020 1 commit
    • Sven Auhagen's avatar
      mvneta driver disallow XDP program on hardware buffer management · 79572c98
      Sven Auhagen authored
      
      
      Recently XDP Support was added to the mvneta driver
      for software buffer management only.
      It is still possible to attach an XDP program if
      hardware buffer management is used.
      It is not doing anything at that point.
      
      The patch disallows attaching XDP programs to mvneta
      if hardware buffer management is used.
      
      I am sorry about that. It is my first submission and I am having
      some troubles with the format of my emails.
      
      v4 -> v5:
      - Remove extra tabs
      
      v3 -> v4:
      - Please ignore v3 I accidentally submitted
        my other patch with git-send-mail and v4 is correct
      
      v2 -> v3:
      - My mailserver corrupted the patch
        resubmission with git-send-email
      
      v1 -> v2:
      - Fixing the patches indentation
      
      Signed-off-by: default avatarSven Auhagen <sven.auhagen@voleatech.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79572c98
  4. 15 Jan, 2020 1 commit
  5. 14 Jan, 2020 1 commit
  6. 24 Nov, 2019 1 commit
  7. 20 Nov, 2019 2 commits
  8. 15 Nov, 2019 1 commit
  9. 04 Nov, 2019 1 commit
    • Andrew Lunn's avatar
      net: of_get_phy_mode: Change API to solve int/unit warnings · 0c65b2b9
      Andrew Lunn authored
      
      
      Before this change of_get_phy_mode() returned an enum,
      phy_interface_t. On error, -ENODEV etc, is returned. If the result of
      the function is stored in a variable of type phy_interface_t, and the
      compiler has decided to represent this as an unsigned int, comparision
      with -ENODEV etc, is a signed vs unsigned comparision.
      
      Fix this problem by changing the API. Make the function return an
      error, or 0 on success, and pass a pointer, of type phy_interface_t,
      where the phy mode should be stored.
      
      v2:
      Return with *interface set to PHY_INTERFACE_MODE_NA on error.
      Add error checks to all users of of_get_phy_mode()
      Fixup a few reverse christmas tree errors
      Fixup a few slightly malformed reverse christmas trees
      
      v3:
      Fix 0-day reported errors.
      
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c65b2b9
  10. 21 Oct, 2019 7 commits
  11. 26 Jul, 2019 1 commit
  12. 23 Jul, 2019 1 commit
  13. 10 Jun, 2019 1 commit
  14. 30 May, 2019 1 commit
    • Ioana Ciornei's avatar
      net: phylink: Add struct phylink_config to PHYLINK API · 44cc27e4
      Ioana Ciornei authored
      
      
      The phylink_config structure will encapsulate a pointer to a struct
      device and the operation type requested for this instance of PHYLINK.
      This patch does not make any functional changes, it just transitions the
      PHYLINK internals and all its users to the new API.
      
      A pointer to a phylink_config structure will be passed to
      phylink_create() instead of the net_device directly. Also, the same
      phylink_config pointer will be passed back to all phylink_mac_ops
      callbacks instead of the net_device. Using this mechanism, a PHYLINK
      user can get the original net_device using a structure such as
      'to_net_dev(config->dev)' or directly the structure containing the
      phylink_config using a container_of call.
      
      At the moment, only the PHYLINK_NETDEV is defined as a valid operation
      type for PHYLINK. In this mode, a valid reference to a struct device
      linked to the original net_device should be passed to PHYLINK through
      the phylink_config structure.
      
      This API changes is mainly driven by the necessity of adding a new
      operation type in PHYLINK that disconnects the phy_device from the
      net_device and also works when the net_device is lacking.
      
      Signed-off-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Tested-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44cc27e4
  15. 28 May, 2019 1 commit
  16. 10 May, 2019 1 commit
    • Petr Štetiar's avatar
      net: ethernet: fix similar warning reported by kbuild test robot · 2d2924af
      Petr Štetiar authored
      This patch fixes following (similar) warning reported by kbuild test robot:
      
       In function ‘memcpy’,
        inlined from ‘smsc75xx_init_mac_address’ at drivers/net/usb/smsc75xx.c:778:3,
        inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
        ./include/linux/string.h:355:9: warning: argument 2 null where non-null expected [-Wnonnull]
        return __builtin_memcpy(p, q, size);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
        drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
        ./include/linux/string.h:355:9: note: in a call to built-in function ‘__builtin_memcpy’
      
      I've replaced the offending memcpy with ether_addr_copy, because I'm
      100% sure, that of_get_mac_address can't return NULL as it returns valid
      pointer or ERR_PTR encoded value, nothing else.
      
      I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
      would make the warning disappear also, but it would be confusing to
      check for impossible return value just to make a compiler happy.
      
      I'm now changing all occurencies of memcpy to ether_addr_copy after the
      of_get_mac_address call, as it's very likely, that we're going to get
      similar reports from kbuild test robot in the future.
      
      Fixes: a51645f7
      
       ("net: ethernet: support of_get_mac_address new ERR_PTR error")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d2924af
  17. 07 May, 2019 1 commit
  18. 24 Apr, 2019 1 commit
  19. 02 Apr, 2019 1 commit
    • Florian Westphal's avatar
      net: move skb->xmit_more hint to softnet data · 6b16f9ee
      Florian Westphal authored
      
      
      There are two reasons for this.
      
      First, the xmit_more flag conceptually doesn't fit into the skb, as
      xmit_more is not a property related to the skb.
      Its only a hint to the driver that the stack is about to transmit another
      packet immediately.
      
      Second, it was only done this way to not have to pass another argument
      to ndo_start_xmit().
      
      We can place xmit_more in the softnet data, next to the device recursion.
      The recursion counter is already written to on each transmit. The "more"
      indicator is placed right next to it.
      
      Drivers can use the netdev_xmit_more() helper instead of skb->xmit_more
      to check the "more packets coming" hint.
      
      skb->xmit_more is retained (but always 0) to not cause build breakage.
      
      This change takes care of the simple s/skb->xmit_more/netdev_xmit_more()/
      conversions.  Remaining drivers are converted in the next patches.
      
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b16f9ee
  20. 29 Mar, 2019 1 commit
    • Maxime Chevallier's avatar
      net: mvneta: Add 2500BaseT support · eda3d1b0
      Maxime Chevallier authored
      
      
      Some PHYs will use the 2500BaseX PHY_INTERFACE_MODE when being linked
      with a partner using 2.5GBaseT.
      
      Since we can't autonegotiate this speed between the MAC and the PHY, we
      need to have the proper comphy support enabled, to make sure we can
      safely advertise 2.5G and 1G in BaseT and be able to switch between both
      corresponding PHY interface modes. This is now possible since comphy
      support was added to this driver.
      
      This commit adds the 2500BaseT mode to the list of supported modes when
      using 2500BaseX, and was tested on a setup with an Armada385 and a
      88E2010 PHY, both with and without the comphy node in the DT.
      
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eda3d1b0
  21. 01 Mar, 2019 1 commit
    • Marek Behún's avatar
      net: marvell: neta: disable comphy when setting mode · 031b922b
      Marek Behún authored
      
      
      The comphy driver for Armada 3700 by Miquèl Raynal (which is currently
      in linux-next) does not actually set comphy mode when phy_set_mode_ext
      is called. The mode is set at next call of phy_power_on.
      
      Update the driver to semantics similar to mvpp2: helper
      mvneta_comphy_init sets comphy mode and powers it on.
      When mode is to be changed in mvneta_mac_config, first power the comphy
      off, then call mvneta_comphy_init (which sets the mode to new one).
      
      Only do this when new mode is different from old mode.
      
      This should also work for Armada 38x, since in that comphy driver
      methods power_on and power_off are unimplemented.
      
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      031b922b
  22. 21 Feb, 2019 1 commit
    • Russell King's avatar
      net: marvell: mvneta: fix DMA debug warning · a8fef9ba
      Russell King authored
      
      
      Booting 4.20 on SolidRun Clearfog issues this warning with DMA API
      debug enabled:
      
      WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc
      mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes]
      Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables
      CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291
      Hardware name: Marvell Armada 380/385 (Device Tree)
      [<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14)
      [<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4)
      [<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124)
      [<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48)
      [<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc)
      [<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74)
      [<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58)
      [<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424)
      [<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540)
      [<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144)
      [<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0)
      [<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98)
      [<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98)
      ...
      
      This appears to be caused by mvneta_rx_hwbm() calling
      dma_sync_single_range_for_cpu() with the wrong struct device pointer,
      as the buffer manager device pointer is used to map and unmap the
      buffer.  Fix this.
      
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8fef9ba
  23. 08 Feb, 2019 1 commit
  24. 16 Dec, 2018 1 commit
    • Marcin Wojtas's avatar
      net: mvneta: fix operation for 64K PAGE_SIZE · e735fd55
      Marcin Wojtas authored
      Recent changes in the mvneta driver reworked allocation
      and handling of the ingress buffers to use entire pages.
      Apart from that in SW BM scenario the HW must be informed
      via PRXDQS about the biggest possible incoming buffer
      that can be propagated by RX descriptors.
      
      The BufferSize field was filled according to the MTU-dependent
      pkt_size value. Later change to PAGE_SIZE broke RX operation
      when usin 64K pages, as the field is simply too small.
      
      This patch conditionally limits the value passed to the BufferSize
      of the PRXDQS register, depending on the PAGE_SIZE used.
      On the occasion remove now unused frag_size field of the mvneta_port
      structure.
      
      Fixes: 562e2f46
      
       ("net: mvneta: Improve the buffer allocation method for SWBM")
      Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e735fd55
  25. 24 Nov, 2018 1 commit
  26. 17 Nov, 2018 1 commit
  27. 10 Nov, 2018 1 commit
  28. 27 Sep, 2018 1 commit
    • Maxime Chevallier's avatar
      net: mvneta: Add support for 2500Mbps SGMII · da58a931
      Maxime Chevallier authored
      
      
      The mvneta controller can handle speeds up to 2500Mbps on the SGMII
      interface. This relies on serdes configuration, the lane must be
      configured at 3.125Gbps and we can't use in-band autoneg at that speed.
      
      The main issue when supporting that speed on this particular controller
      is that the link partner can send ethernet frames with a shortened
      preamble, which if not explicitly enabled in the controller will cause
      unexpected behaviours.
      
      This was tested on Armada 385, with the comphy configuration done in
      bootloader.
      
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da58a931
  29. 24 Sep, 2018 1 commit
  30. 20 Sep, 2018 3 commits
  31. 02 Sep, 2018 1 commit