1. 03 6月, 2014 2 次提交
  2. 24 5月, 2014 6 次提交
  3. 23 5月, 2014 3 次提交
  4. 17 5月, 2014 1 次提交
  5. 14 5月, 2014 1 次提交
  6. 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
  7. 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
  8. 30 3月, 2014 1 次提交
  9. 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
  10. 15 3月, 2014 1 次提交
  11. 15 2月, 2014 1 次提交
  12. 17 1月, 2014 13 次提交
    • A
      net: mvneta: make mvneta_txq_done() return void · cd713199
      Arnaud Ebalard 提交于
      The function return parameter is not used in mvneta_tx_done_gbe(),
      where the function is called. This patch makes the function return
      void.
      Reviewed-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd713199
    • A
      net: mvneta: mvneta_tx_done_gbe() cleanups · 0713a86a
      Arnaud Ebalard 提交于
      mvneta_tx_done_gbe() return value and third parameter are no more
      used. This patch changes the function prototype and removes a useless
      variable where the function is called.
      Reviewed-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0713a86a
    • W
      net: mvneta: implement rx_copybreak · f19fadfc
      willy tarreau 提交于
      calling dma_map_single()/dma_unmap_single() is quite expensive compared
      to copying a small packet. So let's copy short frames and keep the buffers
      mapped. We set the limit to 256 bytes which seems to give good results both
      on the XP-GP board and on the AX3/4.
      
      The Rx small packet rate increased by 16.4% doing this, from 486kpps to
      573kpps. It is worth noting that even the call to the function
      dma_sync_single_range_for_cpu() is expensive (300 ns) although less
      than dma_unmap_single(). Without it, the packet rate raises to 711kpps
      (+24% more). Thus on systems where coherency from device to CPU is
      guaranteed by a snoop control unit, this patch should provide even more
      gains, and probably rx_copybreak could be increased.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      f19fadfc
    • W
      net: mvneta: convert to build_skb() · 8ec2cd48
      willy tarreau 提交于
      Make use of build_skb() to allocate frags on the RX path. When frag size
      is lower than a page size, we can use netdev_alloc_frag(), and we fall back
      to kmalloc() for larger sizes. The frag size is stored into the mvneta_port
      struct. The alloc/free functions check the frag size to decide what alloc/
      free method to use. MTU changes are safe because the MTU change function
      stops the device and clears the queues before applying the change.
      
      With this patch, I observed a reproducible 2% performance improvement on
      HTTP-based benchmarks, and 5% on small packet RX rate.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      8ec2cd48
    • W
      net: mvneta: prefetch next rx descriptor instead of current one · 34e4179d
      willy tarreau 提交于
      Currently, the mvneta driver tries to prefetch the current Rx
      descriptor during read. Tests have shown that prefetching the
      next one instead increases general performance by about 1% on
      HTTP traffic.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      34e4179d
    • W
      net: mvneta: simplify access to the rx descriptor status · 5428213c
      willy tarreau 提交于
      At several places, we already know the value of the rx status but
      we call functions which dereference the pointer again to get it
      and don't need the descriptor for anything else. Simplify this
      task by replacing the rx desc pointer by the status word itself.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      5428213c
    • W
      net: mvneta: factor rx refilling code · a1a65ab1
      willy tarreau 提交于
      Make mvneta_rxq_fill() use mvneta_rx_refill() instead of using
      duplicate code.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      a1a65ab1
    • W
      net: mvneta: remove tests for impossible cases in the tx_done path · 6c498974
      willy tarreau 提交于
      Currently, mvneta_txq_bufs_free() calls mvneta_tx_done_policy() with
      a non-null cause to retrieve the pointer to the next queue to process.
      There are useless tests on the return queue number and on the pointer,
      all of which are well defined within a known limited set. This code
      path is fast, although not critical. Removing 3 tests here that the
      compiler could not optimize (verified) is always desirable.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      6c498974
    • W
      net: mvneta: replace Tx timer with a real interrupt · 71f6d1b3
      willy tarreau 提交于
      Right now the mvneta driver doesn't handle Tx IRQ, and relies on two
      mechanisms to flush Tx descriptors : a flush at the end of mvneta_tx()
      and a timer. If a burst of packets is emitted faster than the device
      can send them, then the queue is stopped until next wake-up of the
      timer 10ms later. This causes jerky output traffic with bursts and
      pauses, making it difficult to reach line rate with very few streams.
      
      A test on UDP traffic shows that it's not possible to go beyond 134
      Mbps / 12 kpps of outgoing traffic with 1500-bytes IP packets. Routed
      traffic tends to observe pauses as well if the traffic is bursty,
      making it even burstier after the wake-up.
      
      It seems that this feature was inherited from the original driver but
      nothing there mentions any reason for not using the interrupt instead,
      which the chip supports.
      
      Thus, this patch enables Tx interrupts and removes the timer. It does
      the two at once because it's not really possible to make the two
      mechanisms coexist, so a split patch doesn't make sense.
      
      First tests performed on a Mirabox (Armada 370) show that less CPU
      seems to be used when sending traffic. One reason might be that we now
      call the mvneta_tx_done_gbe() with a mask indicating which queues have
      been done instead of looping over all of them.
      
      The same UDP test above now happily reaches 987 Mbps / 87.7 kpps.
      Single-stream TCP traffic can now more easily reach line rate. HTTP
      transfers of 1 MB objects over a single connection went from 730 to
      840 Mbps. It is even possible to go significantly higher (>900 Mbps)
      by tweaking tcp_tso_win_divisor.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Arnaud Ebalard <arno@natisbad.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.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>
      71f6d1b3
    • W
      net: mvneta: add missing bit descriptions for interrupt masks and causes · 40ba35e7
      willy tarreau 提交于
      Marvell has not published the chip's datasheet yet, so it's very hard
      to find the relevant bits to manipulate to change the IRQ behaviour.
      Fortunately, these bits are described in the proprietary LSP patch set
      which is publicly available here :
      
          http://www.plugcomputer.org/downloads/mirabox/
      
      So let's put them back in the driver in order to reduce the burden of
      current and future maintenance.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.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>
      40ba35e7
    • W
      net: mvneta: do not schedule in mvneta_tx_timeout · 29021366
      willy tarreau 提交于
      If a queue timeout is reported, we can oops because of some
      schedules while the caller is atomic, as shown below :
      
        mvneta d0070000.ethernet eth0: tx timeout
        BUG: scheduling while atomic: bash/1528/0x00000100
        Modules linked in: slhttp_ethdiv(C) [last unloaded: slhttp_ethdiv]
        CPU: 2 PID: 1528 Comm: bash Tainted: G        WC   3.13.0-rc4-mvebu-nf #180
        [<c0011bd9>] (unwind_backtrace+0x1/0x98) from [<c000f1ab>] (show_stack+0xb/0xc)
        [<c000f1ab>] (show_stack+0xb/0xc) from [<c02ad323>] (dump_stack+0x4f/0x64)
        [<c02ad323>] (dump_stack+0x4f/0x64) from [<c02abe67>] (__schedule_bug+0x37/0x4c)
        [<c02abe67>] (__schedule_bug+0x37/0x4c) from [<c02ae261>] (__schedule+0x325/0x3ec)
        [<c02ae261>] (__schedule+0x325/0x3ec) from [<c02adb97>] (schedule_timeout+0xb7/0x118)
        [<c02adb97>] (schedule_timeout+0xb7/0x118) from [<c0020a67>] (msleep+0xf/0x14)
        [<c0020a67>] (msleep+0xf/0x14) from [<c01dcbe5>] (mvneta_stop_dev+0x21/0x194)
        [<c01dcbe5>] (mvneta_stop_dev+0x21/0x194) from [<c01dcfe9>] (mvneta_tx_timeout+0x19/0x24)
        [<c01dcfe9>] (mvneta_tx_timeout+0x19/0x24) from [<c024afc7>] (dev_watchdog+0x18b/0x1c4)
        [<c024afc7>] (dev_watchdog+0x18b/0x1c4) from [<c0020b53>] (call_timer_fn.isra.27+0x17/0x5c)
        [<c0020b53>] (call_timer_fn.isra.27+0x17/0x5c) from [<c0020cad>] (run_timer_softirq+0x115/0x170)
        [<c0020cad>] (run_timer_softirq+0x115/0x170) from [<c001ccb9>] (__do_softirq+0xbd/0x1a8)
        [<c001ccb9>] (__do_softirq+0xbd/0x1a8) from [<c001cfad>] (irq_exit+0x61/0x98)
        [<c001cfad>] (irq_exit+0x61/0x98) from [<c000d4bf>] (handle_IRQ+0x27/0x60)
        [<c000d4bf>] (handle_IRQ+0x27/0x60) from [<c000843b>] (armada_370_xp_handle_irq+0x33/0xc8)
        [<c000843b>] (armada_370_xp_handle_irq+0x33/0xc8) from [<c000fba9>] (__irq_usr+0x49/0x60)
      
      Ben Hutchings attempted to propose a better fix consisting in using a
      scheduled work for this, but while it fixed this panic, it caused other
      random freezes and panics proving that the reset sequence in the driver
      is unreliable and that additional fixes should be investigated.
      
      When sending multiple streams over a link limited to 100 Mbps, Tx timeouts
      happen from time to time, and the driver correctly recovers only when the
      function is disabled.
      
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Tested-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29021366
    • 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
  13. 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
  14. 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
  15. 30 10月, 2013 1 次提交
  16. 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
  17. 31 7月, 2013 1 次提交