1. 28 2月, 2020 2 次提交
  2. 21 2月, 2020 1 次提交
  3. 20 2月, 2020 1 次提交
  4. 17 2月, 2020 5 次提交
  5. 06 2月, 2020 1 次提交
  6. 29 1月, 2020 1 次提交
  7. 27 1月, 2020 1 次提交
    • S
      mvneta driver disallow XDP program on hardware buffer management · 79572c98
      Sven Auhagen 提交于
      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: NSven Auhagen <sven.auhagen@voleatech.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79572c98
  8. 15 1月, 2020 1 次提交
  9. 14 1月, 2020 1 次提交
  10. 24 11月, 2019 1 次提交
  11. 21 11月, 2019 2 次提交
  12. 15 11月, 2019 1 次提交
  13. 05 11月, 2019 1 次提交
    • A
      net: of_get_phy_mode: Change API to solve int/unit warnings · 0c65b2b9
      Andrew Lunn 提交于
      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: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c65b2b9
  14. 22 10月, 2019 7 次提交
  15. 26 7月, 2019 1 次提交
  16. 23 7月, 2019 1 次提交
  17. 10 6月, 2019 1 次提交
  18. 30 5月, 2019 1 次提交
    • I
      net: phylink: Add struct phylink_config to PHYLINK API · 44cc27e4
      Ioana Ciornei 提交于
      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: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Tested-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44cc27e4
  19. 29 5月, 2019 1 次提交
  20. 11 5月, 2019 1 次提交
    • P
      net: ethernet: fix similar warning reported by kbuild test robot · 2d2924af
      Petr Štetiar 提交于
      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: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NPetr Štetiar <ynezz@true.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d2924af
  21. 08 5月, 2019 1 次提交
  22. 25 4月, 2019 1 次提交
  23. 02 4月, 2019 1 次提交
    • F
      net: move skb->xmit_more hint to softnet data · 6b16f9ee
      Florian Westphal 提交于
      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: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b16f9ee
  24. 29 3月, 2019 1 次提交
    • M
      net: mvneta: Add 2500BaseT support · eda3d1b0
      Maxime Chevallier 提交于
      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: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eda3d1b0
  25. 02 3月, 2019 1 次提交
    • M
      net: marvell: neta: disable comphy when setting mode · 031b922b
      Marek Behún 提交于
      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: NMarek Behún <marek.behun@nic.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      031b922b
  26. 21 2月, 2019 1 次提交
    • R
      net: marvell: mvneta: fix DMA debug warning · a8fef9ba
      Russell King 提交于
      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: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8fef9ba
  27. 08 2月, 2019 1 次提交
  28. 17 12月, 2018 1 次提交
    • M
      net: mvneta: fix operation for 64K PAGE_SIZE · e735fd55
      Marcin Wojtas 提交于
      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: NMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e735fd55