1. 22 7月, 2015 1 次提交
  2. 21 7月, 2015 1 次提交
    • S
      net: mvneta: fix refilling for Rx DMA buffers · a84e3289
      Simon Guinot 提交于
      With the actual code, if a memory allocation error happens while
      refilling a Rx descriptor, then the original Rx buffer is both passed
      to the networking stack (in a SKB) and let in the Rx ring. This leads
      to various kernel oops and crashes.
      
      As a fix, this patch moves Rx descriptor refilling ahead of building
      SKB with the associated Rx buffer. In case of a memory allocation
      failure, data is dropped and the original DMA buffer is put back into
      the Rx ring.
      Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
      Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit")
      Cc: <stable@vger.kernel.org> # v3.8+
      Tested-by: NYoann Sculo <yoann@sculo.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a84e3289
  3. 01 7月, 2015 2 次提交
  4. 23 6月, 2015 1 次提交
  5. 12 5月, 2015 1 次提交
  6. 07 4月, 2015 1 次提交
  7. 04 4月, 2015 1 次提交
  8. 09 12月, 2014 2 次提交
    • E
      net: mvneta: fix race condition in mvneta_tx() · 5f478b41
      Eric Dumazet 提交于
      mvneta_tx() dereferences skb to get skb->len too late,
      as hardware might have completed the transmit and TX completion
      could have freed the skb from another cpu.
      
      Fixes: 71f6d1b3 ("net: mvneta: replace Tx timer with a real interrupt")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f478b41
    • W
      net: mvneta: fix Tx interrupt delay · aebea2ba
      willy tarreau 提交于
      The mvneta driver sets the amount of Tx coalesce packets to 16 by
      default. Normally that does not cause any trouble since the driver
      uses a much larger Tx ring size (532 packets). But some sockets
      might run with very small buffers, much smaller than the equivalent
      of 16 packets. This is what ping is doing for example, by setting
      SNDBUF to 324 bytes rounded up to 2kB by the kernel.
      
      The problem is that there is no documented method to force a specific
      packet to emit an interrupt (eg: the last of the ring) nor is it
      possible to make the NIC emit an interrupt after a given delay.
      
      In this case, it causes trouble, because when ping sends packets over
      its raw socket, the few first packets leave the system, and the first
      15 packets will be emitted without an IRQ being generated, so without
      the skbs being freed. And since the socket's buffer is small, there's
      no way to reach that amount of packets, and the ping ends up with
      "send: no buffer available" after sending 6 packets. Running with 3
      instances of ping in parallel is enough to hide the problem, because
      with 6 packets per instance, that's 18 packets total, which is enough
      to grant a Tx interrupt before all are sent.
      
      The original driver in the LSP kernel worked around this design flaw
      by using a software timer to clean up the Tx descriptors. This timer
      was slow and caused terrible network performance on some Tx-bound
      workloads (such as routing) but was enough to make tools like ping
      work correctly.
      
      Instead here, we simply set the packet counts before interrupt to 1.
      This ensures that each packet sent will produce an interrupt. NAPI
      takes care of coalescing interrupts since the interrupt is disabled
      once generated.
      
      No measurable performance impact nor CPU usage were observed on small
      nor large packets, including when saturating the link on Tx, and this
      fixes tools like ping which rely on too small a send buffer. If one
      wants to increase this value for certain workloads where it is safe
      to do so, "ethtool -C $dev tx-frames" will override this default
      setting.
      
      This fix needs to be applied to stable kernels starting with 3.10.
      Tested-By: NMaggie Mae Roxas <maggie.mae.roxas@gmail.com>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aebea2ba
  9. 01 11月, 2014 1 次提交
  10. 26 8月, 2014 2 次提交
  11. 08 8月, 2014 1 次提交
  12. 09 7月, 2014 2 次提交
    • T
      net: mvneta: Fix big endian issue in mvneta_txq_desc_csum() · 0a198587
      Thomas Fitzsimmons 提交于
      This commit fixes the command value generated for CSUM calculation
      when running in big endian mode.  The Ethernet protocol ID for IP was
      being unconditionally byte-swapped in the layer 3 protocol check (with
      swab16), which caused the mvneta driver to not function correctly in
      big endian mode.  This patch byte-swaps the ID conditionally with
      htons.
      
      Cc: <stable@vger.kernel.org> # v3.13+
      Signed-off-by: NThomas Fitzsimmons <fitzsim@fitzsim.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a198587
    • T
      net: mvneta: fix operation in 10 Mbit/s mode · 4d12bc63
      Thomas Petazzoni 提交于
      As reported by Maggie Mae Roxas, the mvneta driver doesn't behave
      properly in 10 Mbit/s mode. This is due to a misconfiguration of the
      MVNETA_GMAC_AUTONEG_CONFIG register: bit MVNETA_GMAC_CONFIG_MII_SPEED
      must be set for a 100 Mbit/s speed, but cleared for a 10 Mbit/s speed,
      which the driver was not properly doing. This commit adjusts that by
      setting the MVNETA_GMAC_CONFIG_MII_SPEED bit only in 100 Mbit/s mode,
      and relying on the fact that all the speed related bits of this
      register are cleared at the beginning of the mvneta_adjust_link()
      function.
      
      This problem exists since c5aff182 ("net: mvneta: driver for
      Marvell Armada 370/XP network unit") which is the commit that
      introduced the mvneta driver in the kernel.
      
      Cc: <stable@vger.kernel.org> # v3.8+
      Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit")
      Reported-by: NMaggie Mae Roxas <maggie.mae.roxas@gmail.com>
      Cc: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d12bc63
  13. 03 6月, 2014 4 次提交
  14. 24 5月, 2014 6 次提交
  15. 23 5月, 2014 3 次提交
  16. 17 5月, 2014 1 次提交
  17. 14 5月, 2014 1 次提交
  18. 17 4月, 2014 1 次提交
    • T
      net: mvneta: properly configure the MAC <-> PHY connection in all situations · 3f1dd4bc
      Thomas Petazzoni 提交于
      Commit 5445eaf3 ('mvneta: Try to fix mvneta when compiled as
      module') fixed the mvneta driver to make it work properly when loaded
      as a module in SGMII configuration, which was tested successful by the
      author on the Armada XP OpenBlocks AX3, which uses SGMII.
      
      However, some other platforms, namely the Armada XP GP don't use
      SGMII, but a QSGMII connection between the MAC and the PHY, and this
      case was not supported by the mvneta driver, which was relying on
      configuration put in place by the bootloader. While this works when
      the mvneta driver is built-in (because clocks are not gated), it
      breaks when mvneta is built as a module, because the clock is gated
      (all configuration is lost) and then re-enabled when the mvneta driver
      is loaded.
      
      In order to support all of RGMII, SGMII and QSGMII, this commit
      reworks how the PHY interface configuration is done, and simplifies
      it: it removes the mvneta_port_sgmii_config() and
      mvneta_gmac_rgmii_set() functions, which were strange because
      mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
      configurations. Also, the mvneta_gmac_rgmii_set() function was taking
      a boolean as argument, which was always true.
      
      Instead, all the PHY interface configuration logic is moved into the
      mvneta_port_power_up() function, in a much simpler 'switch' construct,
      with four cases:
      
       - QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
         the SERDES is configured in QSGMII. Technically speaking,
         configuring the SERDES of the first port would be sufficient, but
         it is simpler to do it on all ports.
      
       - SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
         the SERDES is configured as SGMII.
      
       - RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
         cleared, and no SERDES configuration is done, because RGMII is not
         using SERDES lanes.
      
       - other: an error is returned. For this reason, the
         mvneta_port_power_up() now returns an int instead of nothing, and
         the return value is checked by mvneta_probe().
      
      This has been successfully tested on:
      
       * Armada XP DB, which has two RGMII and two SGMII connections
       * Armada XP GP, which uses QSGMII for its four interfaces
       * Armada 370 Mirabox, which has two RGMII connections
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f1dd4bc
  19. 14 4月, 2014 1 次提交
    • T
      Revert "net: mvneta: fix usage as a module on RGMII configurations" · cc6ca302
      Thomas Petazzoni 提交于
      This reverts commit e3a8786c. While
      this commit allows to use the mvneta driver as a module on some
      configurations, it breaks other configurations even if mvneta is used
      built-in.
      
      This breakage is due to the fact that on some RGMII platforms, the PCS
      bit has to be set, and on some other platforms, it has to be
      cleared. At the moment, we lack informations to know exactly the
      significance of this bit (the datasheet only says "enables PCS"), and
      so we can't produce a patch that will work on all platforms at this
      point. And since this change is breaking the network completely for
      many users, it's much better to revert it for now. We'll come back
      later with a proper fix that takes into account all platforms.
      
      Basically:
      
       * Armada XP GP is configured as RGMII-ID, and needs the PCS bit to be
         set.
       * Armada 370 Mirabox is configured as RGMII-ID, and needs the PCS bit
         to be cleared.
      
      And at the moment, we don't know how to make the distinction between
      those two cases. One hint is that the Armada XP GP appears in fact to
      be using a QSGMII connection with the PHY (Quad-SGMII), but
      configuring it as SGMII doesn't work, while RGMII-ID works. This needs
      more investigation, but in the mean time, let's unbreak the network
      for all those users.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reported-by: NArnaud Ebalard <arno@natisbad.org>
      Reported-by: NAlexander Reuter <Alexander.Reuter@gmx.net>
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=73401
      Cc: stable@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc6ca302
  20. 30 3月, 2014 1 次提交
  21. 27 3月, 2014 3 次提交
    • T
      net: mvneta: use devm_ioremap_resource() instead of of_iomap() · b5f3b75d
      Thomas Petazzoni 提交于
      The mvneta driver currently uses of_iomap(), which has two drawbacks:
      it doesn't request the resource, and it isn't devm-style so some error
      handling is needed.
      
      This commit switches to use devm_ioremap_resource() instead, which
      automatically requests the resource (so the I/O registers region shows
      up properly in /proc/iomem), and also is devm-style, which allows to
      get rid of some error handling to unmap the I/O registers region.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5f3b75d
    • T
      net: mvneta: fix usage as a module on RGMII configurations · e3a8786c
      Thomas Petazzoni 提交于
      Commit 5445eaf3 ('mvneta: Try to fix mvneta when compiled as
      module') fixed the mvneta driver to make it work properly when loaded
      as a module in SGMII configuration, which was tested successful by the
      author on the Armada XP OpenBlocks AX3, which uses SGMII.
      
      However, it turns out that the Armada XP GP, which uses RGMII, is
      affected by a similar problem: its SERDES configuration is lost when
      mvneta is loaded as a module, because this configuration is set by the
      bootloader, and then lost because the clock is gated by the clock
      framework until the mvneta driver is loaded again and the clock is
      re-enabled.
      
      However, it turns out that for the RGMII case, setting the SERDES
      configuration is not sufficient: the PCS enable bit in the
      MVNETA_GMAC_CTRL_2 register must also be set, like in the SGMII
      configuration.
      
      Therefore, this commit reworks the SGMII/RGMII initialization: the
      only difference between the two now is a different SERDES
      configuration, all the rest is identical.
      
      In detail, to achieve this, the commit:
      
       * Renames MVNETA_SGMII_SERDES_CFG to MVNETA_SERDES_CFG because it is
         not specific to SGMII, but also used on RGMII configurations.
      
       * Adds a MVNETA_RGMII_SERDES_PROTO definition, that must be used as
         the MVNETA_SERDES_CFG value in RGMII configurations.
      
       * Removes the mvneta_gmac_rgmii_set() and mvneta_port_sgmii_config()
         functions, and instead directly do the SGMII/RGMII configuration in
         mvneta_port_up(), from where those functions where called. It is
         worth mentioning that mvneta_gmac_rgmii_set() had an 'enable'
         parameter that was always passed as '1', so it was pretty useless.
      
       * Reworks the mvneta_port_up() function to set the MVNETA_SERDES_CFG
         register to the appropriate value depending on the RGMII vs. SGMII
         configuration. It also unconditionally set the PCS_ENABLE bit (was
         already done for SGMII, but is now also needed for RGMII), and sets
         the PORT_RGMII bit (which was already done for both SGMII and
         RGMII).
      
      This commit was successfully tested with mvneta compiled as a module,
      on both the OpenBlocks AX3 (SGMII configuration) and the Armada XP GP
      (RGMII configuration).
      Reported-by: NSteve McIntyre <steve@einval.com>
      Cc: stable@vger.kernel.org # 3.11.x: 5445eaf3 mvneta: Try to fix mvneta when compiled as module
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3a8786c
    • T
      net: mvneta: rename MVNETA_GMAC2_PSC_ENABLE to MVNETA_GMAC2_PCS_ENABLE · a79121d3
      Thomas Petazzoni 提交于
      Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS,
      not the PSC: there was a typo in the name of the define, which this
      commit fixes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a79121d3
  22. 15 3月, 2014 1 次提交
  23. 15 2月, 2014 1 次提交
  24. 17 1月, 2014 1 次提交