1. 17 1月, 2014 2 次提交
    • W
      net: mvneta: use per_cpu stats to fix an SMP lock up · 74c41b04
      willy tarreau 提交于
      Stats writers are mvneta_rx() and mvneta_tx(). They don't lock anything
      when they update the stats, and as a result, it randomly happens that
      the stats freeze on SMP if two updates happen during stats retrieval.
      This is very easily reproducible by starting two HTTP servers and binding
      each of them to a different CPU, then consulting /proc/net/dev in loops
      during transfers, the interface should immediately lock up. This issue
      also randomly happens upon link state changes during transfers, because
      the stats are collected in this situation, but it takes more attempts to
      reproduce it.
      
      The comments in netdevice.h suggest using per_cpu stats instead to get
      rid of this issue.
      
      This patch implements this. It merges both rx_stats and tx_stats into
      a single "stats" member with a single syncp. Both mvneta_rx() and
      mvneta_rx() now only update the a single CPU's counters.
      
      In turn, mvneta_get_stats64() does the summing by iterating over all CPUs
      to get their respective stats.
      
      With this change, stats are still correct and no more lockup is encountered.
      
      Note that this bug was present since the first import of the mvneta
      driver.  It might make sense to backport it to some stable trees. If
      so, it depends on "d33dc73 net: mvneta: increase the 64-bit rx/tx stats
      out of the hot path".
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74c41b04
    • W
      net: mvneta: increase the 64-bit rx/tx stats out of the hot path · dc4277dd
      willy tarreau 提交于
      Better count packets and bytes in the stack and on 32 bit then
      accumulate them at the end for once. This saves two memory writes
      and two memory barriers per packet. The incoming packet rate was
      increased by 4.7% on the Openblocks AX3 thanks to this.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dc4277dd
  2. 07 12月, 2013 1 次提交
    • E
      net: mvneta: Fix incorrect DMA unmapping size · a328f3a0
      Ezequiel Garcia 提交于
      The current code unmaps the DMA mapping created for rx skb_buff's by
      using the data_size as the the mapping size. This is wrong since the
      correct size to specify should match the size used to create the mapping.
      
      This commit removes the following DMA_API_DEBUG warning:
      
      ------------[ cut here ]------------
      WARNING: at lib/dma-debug.c:887 check_unmap+0x3a8/0x860()
      mvneta d0070000.ethernet: DMA-API: device driver frees DMA memory with different size [device address=0x000000002eb80000] [map size=1600 bytes] [unmap size=66 bytes]
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.21-01444-ga88ae13-dirty #92
      [<c0013600>] (unwind_backtrace+0x0/0xf8) from [<c0010fb8>] (show_stack+0x10/0x14)
      [<c0010fb8>] (show_stack+0x10/0x14) from [<c001afa0>] (warn_slowpath_common+0x48/0x68)
      [<c001afa0>] (warn_slowpath_common+0x48/0x68) from [<c001b01c>] (warn_slowpath_fmt+0x30/0x40)
      [<c001b01c>] (warn_slowpath_fmt+0x30/0x40) from [<c018d0fc>] (check_unmap+0x3a8/0x860)
      [<c018d0fc>] (check_unmap+0x3a8/0x860) from [<c018d734>] (debug_dma_unmap_page+0x64/0x70)
      [<c018d734>] (debug_dma_unmap_page+0x64/0x70) from [<c0233f78>] (mvneta_rx+0xec/0x468)
      [<c0233f78>] (mvneta_rx+0xec/0x468) from [<c023436c>] (mvneta_poll+0x78/0x16c)
      [<c023436c>] (mvneta_poll+0x78/0x16c) from [<c02db468>] (net_rx_action+0x94/0x160)
      [<c02db468>] (net_rx_action+0x94/0x160) from [<c0021e68>] (__do_softirq+0xe8/0x1d0)
      [<c0021e68>] (__do_softirq+0xe8/0x1d0) from [<c0021ff8>] (do_softirq+0x4c/0x58)
      [<c0021ff8>] (do_softirq+0x4c/0x58) from [<c0022228>] (irq_exit+0x58/0x90)
      [<c0022228>] (irq_exit+0x58/0x90) from [<c000e7c8>] (handle_IRQ+0x3c/0x94)
      [<c000e7c8>] (handle_IRQ+0x3c/0x94) from [<c0008548>] (armada_370_xp_handle_irq+0x4c/0xb4)
      [<c0008548>] (armada_370_xp_handle_irq+0x4c/0xb4) from [<c000dc20>] (__irq_svc+0x40/0x50)
      Exception stack(0xc04f1f70 to 0xc04f1fb8)
      1f60:                                     c1fe46f8 00000000 00001d92 00001d92
      1f80: c04f0000 c04f0000 c04f84a4 c03e081c c05220e7 00000001 c05220e7 c04f0000
      1fa0: 00000000 c04f1fb8 c000eaf8 c004c048 60000113 ffffffff
      [<c000dc20>] (__irq_svc+0x40/0x50) from [<c004c048>] (cpu_startup_entry+0x54/0x128)
      [<c004c048>] (cpu_startup_entry+0x54/0x128) from [<c04c1a14>] (start_kernel+0x29c/0x2f0)
      [<c04c1a14>] (start_kernel+0x29c/0x2f0) from [<00008074>] (0x8074)
      ---[ end trace d4955f6acd178110 ]---
      Mapped at:
       [<c018d600>] debug_dma_map_page+0x4c/0x11c
       [<c0235d6c>] mvneta_setup_rxqs+0x398/0x598
       [<c0236084>] mvneta_open+0x40/0x17c
       [<c02dbbd4>] __dev_open+0x9c/0x100
       [<c02dbe58>] __dev_change_flags+0x7c/0x134
      Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a328f3a0
  3. 06 11月, 2013 1 次提交
    • J
      net: Explicitly initialize u64_stats_sync structures for lockdep · 827da44c
      John Stultz 提交于
      In order to enable lockdep on seqcount/seqlock structures, we
      must explicitly initialize any locks.
      
      The u64_stats_sync structure, uses a seqcount, and thus we need
      to introduce a u64_stats_init() function and use it to initialize
      the structure.
      
      This unfortunately adds a lot of fairly trivial initialization code
      to a number of drivers. But the benefit of ensuring correctness makes
      this worth while.
      
      Because these changes are required for lockdep to be enabled, and the
      changes are quite trivial, I've not yet split this patch out into 30-some
      separate patches, as I figured it would be better to get the various
      maintainers thoughts on how to best merge this change along with
      the seqcount lockdep enablement.
      
      Feedback would be appreciated!
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Roger Luethi <rl@hellgate.ch>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Wensong Zhang <wensong@linux-vs.org>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/1381186321-4906-2-git-send-email-john.stultz@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      827da44c
  4. 30 10月, 2013 1 次提交
  5. 06 9月, 2013 2 次提交
    • T
      net: mvneta: implement ->ndo_do_ioctl() to support PHY ioctls · 15f59456
      Thomas Petazzoni 提交于
      This commit implements the ->ndo_do_ioctl() operation so that the
      PHY-related ioctl() calls can work from userspace, which allows
      applications like mii-tool or mii-diag to do their job.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15f59456
    • T
      net: mvneta: properly disable HW PHY polling and ensure adjust_link() works · 71408602
      Thomas Petazzoni 提交于
      This commit fixes a long-standing bug that has been reported by many
      users: on some Armada 370 platforms, only the network interface that
      has been used in U-Boot to tftp the kernel works properly in
      Linux. The other network interfaces can see a 'link up', but are
      unable to transmit data. The reports were generally made on the Armada
      370-based Mirabox, but have also been given on the Armada 370-RD
      board.
      
      The network MAC in the Armada 370/XP (supported by the mvneta driver
      in Linux) has a functionality that allows it to continuously poll the
      PHY and directly update the MAC configuration accordingly (speed,
      duplex, etc.). The very first versions of the driver submitted for
      review were using this hardware mechanism, but due to this, the driver
      was not integrated with the kernel phylib. Following reviews, the
      driver was changed to use the phylib, and therefore a software based
      polling. In software based polling, Linux regularly talks to the PHY
      over the MDIO bus, and sees if the link status has changed. If it's
      the case then the adjust_link() callback of the driver is called to
      update the MAC configuration accordingly.
      
      However, it turns out that the adjust_link() callback was not
      configuring the hardware in a completely correct way: while it was
      setting the speed and duplex bits correctly, it wasn't telling the
      hardware to actually take into account those bits rather than what the
      hardware-based PHY polling mechanism has concluded. So, in fact the
      adjust_link() callback was basically a no-op.
      
      However, the network happened to be working because on the network
      interfaces used by U-Boot for tftp on Armada 370 platforms because the
      hardware PHY polling was enabled by the bootloader, and left enabled
      by Linux. However, the second network interface not used for tftp (or
      both network interfaces if the kernel is loaded from USB, NAND or SD
      card) didn't had the hardware PHY polling enabled.
      
      This patch fixes this situation by:
      
       (1) Making sure that the hardware PHY polling is disabled by clearing
           the MVNETA_PHY_POLLING_ENABLE bit in the MVNETA_UNIT_CONTROL
           register in the driver ->probe() function.
      
       (2) Making sure that the duplex and speed selections made by the
           adjust_link() callback are taken into account by clearing the
           MVNETA_GMAC_AN_SPEED_EN and MVNETA_GMAC_AN_DUPLEX_EN bits in the
           MVNETA_GMAC_AUTONEG_CONFIG register.
      
      This patch has been tested on Armada 370 Mirabox, and now both network
      interfaces are usable after boot.
      
      [ Problem introduced by commit c5aff182 ("net: mvneta: driver for
        Marvell Armada 370/XP network unit") ]
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Jochen De Smet <jochen.armkernel@leahnim.org>
      Cc: Peter Sanford <psanford@nearbuy.io>
      Cc: Ethan Tuttle <ethan@ethantuttle.com>
      Cc: Chény Yves-Gael <yves@cheny.fr>
      Cc: Ryan Press <ryan@presslab.us>
      Cc: Simon Guinot <simon.guinot@sequanux.org>
      Cc: vdonnefort@lacie.com
      Cc: stable@vger.kernel.org
      Acked-by: NJason Cooper <jason@lakedaemon.net>
      Tested-by: NVincent Donnefort <vdonnefort@gmail.com>
      Tested-by: NYves-Gael Cheny <yves@cheny.fr>
      Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71408602
  6. 31 7月, 2013 4 次提交
  7. 05 6月, 2013 1 次提交
    • T
      net: mvneta: read MAC address from hardware when available · 8cc3e439
      Thomas Petazzoni 提交于
      This patch improves the logic used by the mvneta driver to find a MAC
      address for a particular interface. Until now, it was only looking at
      the Device Tree, and if no address was found, was falling back to
      generating a random MAC address.
      
      This patch adds the intermediate solution of reading the MAC address
      from the hardware registers, in case it has been set by the
      bootloader. So the order is now:
      
       1) MAC address from the Device Tree
       2) MAC address from the hardware registers
       3) Random MAC address
      
      This requires moving the MAC address initialization a little bit later
      in the ->probe() code, because it now requires the hardware registers
      to be remapped.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cc3e439
  8. 28 5月, 2013 1 次提交
  9. 16 4月, 2013 1 次提交
    • W
      net: mvneta: fix improper tx queue usage in mvneta_tx() · ee40a116
      Willy Tarreau 提交于
      mvneta_tx() was using a static tx queue number causing crashes as
      soon as a little bit of traffic was sent via the interface, because
      it is normally expected that the same queue should be used as in
      dev_queue_xmit().
      
      As suggested by Ben Hutchings, let's use skb_get_queue_mapping() to
      get the proper Tx queue number, and use alloc_etherdev_mqs() instead
      of alloc_etherdev_mq() to create the queues.
      
      Both my Mirabox and my OpenBlocks AX3 used to crash without this patch
      and don't anymore with it. The issue appeared in 3.8 but became more
      visible after the fix allowing GSO to be enabled.
      
      Original work was done by Dmitri Epshtein and Thomas Petazzoni. I
      just adapted it to take care of Ben's comments.
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Cc: Dmitri Epshtein <dima@marvell.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee40a116
  10. 09 4月, 2013 1 次提交
  11. 15 3月, 2013 1 次提交
  12. 29 1月, 2013 1 次提交
  13. 22 12月, 2012 1 次提交
  14. 21 11月, 2012 3 次提交
  15. 16 11月, 2012 1 次提交
    • T
      net: mvneta: driver for Marvell Armada 370/XP network unit · c5aff182
      Thomas Petazzoni 提交于
      This patch contains a new network driver for the network unit of the
      ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B
      processor, a Marvell-developed ARM core that implements the ARMv7
      instruction set.
      
      Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery),
      the network unit in Armada 370 and Armada XP is highly different. This
      is the reason why this new 'mvneta' driver is needed, while the older
      ARM Marvell SoCs use the 'mv643xx_eth' driver.
      
      Here is an overview of the most important hardware changes that
      require a new, specific, driver for the network unit of Armada 370/XP:
      
       - The new network unit has a completely different design and layout
         for the RX and TX descriptors. They are now organized as a simple
         array (each RX and TX queue has base address and size of this
         array) rather than a linked list as in the old SoCs.
      
       - The new network unit has a different RXQ and TXQ management: this
         management is done using special read/write counter registers,
         while in the Old SocS, it was done using the Ownership bit in RX
         and TX descriptors.
      
       - The new network unit has different interrupt registers
      
       - The new network unit way of cleaning of interrupts is not done by
         writing to the cause register, but by updating per-queue counters
      
       - The new network unit has different GMAC registers (link, speed,
         duplex configuration) and different WRR registers.
      
       - The new network unit has lots of new units like PnC (Parser and
         Classifier), PMT, BM (Memory Buffer Management), xPON, and more.
      
      The driver proposed in the current patch only handles the basic
      features. Additional hardware features will progressively be supported
      as needed.
      
      This code has originally been written by Rami Rosen
      <rosenr@marvell.com>, and then reviewed and cleaned up by Thomas
      Petazzoni <thomas.petazzoni@free-electrons.com>.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      c5aff182