1. 04 6月, 2019 1 次提交
  2. 24 3月, 2019 1 次提交
    • R
      net: marvell: mvneta: fix DMA debug warning · f3a9c9be
      Russell King 提交于
      [ Upstream commit a8fef9ba58c9966ddb1fec916d8d8137c9d8bc89 ]
      
      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>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f3a9c9be
  3. 10 1月, 2019 1 次提交
    • M
      net: mvneta: fix operation for 64K PAGE_SIZE · e15413d6
      Marcin Wojtas 提交于
      [ Upstream commit e735fd55b94bb48363737db3b1d57627c1a16b47 ]
      
      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>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e15413d6
  4. 25 9月, 2018 1 次提交
  5. 20 9月, 2018 1 次提交
    • A
      net: mvneta: fix the Rx desc buffer DMA unmapping · cf5cca6e
      Antoine Tenart 提交于
      With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the
      mvneta driver:
      
        mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
        wrong function [device address=0x000000001165b000] [size=4096 bytes]
        [mapped as page] [unmapped as single]
      
      This is because when using the s/w buffer management, the Rx descriptor
      buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
      This patch fixes this by using the right unmapping function.
      
      Fixes: 562e2f46 ("net: mvneta: Improve the buffer allocation method for SWBM")
      Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf5cca6e
  6. 11 8月, 2018 1 次提交
  7. 29 7月, 2018 8 次提交
  8. 23 6月, 2018 1 次提交
    • A
      net: mvneta: fix the Rx desc DMA address in the Rx path · 271f7ff5
      Antoine Tenart 提交于
      When using s/w buffer management, buffers are allocated and DMA mapped.
      When doing so on an arm64 platform, an offset correction is applied on
      the DMA address, before storing it in an Rx descriptor. The issue is
      this DMA address is then used later in the Rx path without removing the
      offset correction. Thus the DMA address is wrong, which can led to
      various issues.
      
      This patch fixes this by removing the offset correction from the DMA
      address retrieved from the Rx descriptor before using it in the Rx path.
      
      Fixes: 8d5047cf ("net: mvneta: Convert to be 64 bits compatible")
      Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      271f7ff5
  9. 02 4月, 2018 2 次提交
  10. 31 3月, 2018 2 次提交
  11. 30 3月, 2018 2 次提交
  12. 27 3月, 2018 1 次提交
  13. 03 1月, 2018 9 次提交
  14. 21 12月, 2017 3 次提交
  15. 14 11月, 2017 1 次提交
    • S
      net: mvneta: fix handling of the Tx descriptor counter · 0d63785c
      Simon Guinot 提交于
      The mvneta controller provides a 8-bit register to update the pending
      Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be
      added at once. In the current code the mvneta_txq_pend_desc_add function
      assumes the caller takes care of this limit. But it is not the case. In
      some situations (xmit_more flag), more than 255 descriptors are added.
      When this happens, the Tx descriptor counter register is updated with a
      wrong value, which breaks the whole Tx queue management.
      
      This patch fixes the issue by allowing the mvneta_txq_pend_desc_add
      function to process more than 255 Tx descriptors.
      
      Fixes: 2a90f7e1 ("net: mvneta: add xmit_more support")
      Cc: stable@vger.kernel.org # 4.11+
      Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d63785c
  16. 02 9月, 2017 1 次提交
  17. 24 8月, 2017 1 次提交
  18. 16 6月, 2017 1 次提交
    • J
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg 提交于
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae1d12
  19. 19 4月, 2017 2 次提交