1. 11 4月, 2014 8 次提交
  2. 26 2月, 2014 1 次提交
  3. 18 2月, 2014 1 次提交
  4. 17 2月, 2014 1 次提交
  5. 13 2月, 2014 1 次提交
    • O
      dma: mv_xor: Silence a bunch of LPAE-related warnings · 31fd8f5b
      Olof Johansson 提交于
      Enabling some of the mvebu platforms in the multiplatform config for ARM
      enabled these drivers, which also triggered a bunch of warnings when LPAE
      is enabled (thus making phys_addr_t 64-bit).
      
      Most changes are switching printk formats, but also a bit of changes to what
      used to be array-based pointer arithmetic that could just be done with the
      address types instead.
      
      The warnings were:
      
      drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
      drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
          'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
      drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
      drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
          different size [-Wint-to-pointer-cast]
      drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
          different size [-Wpointer-to-int-cast]
      drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
      drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
          'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
      drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
          'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
      drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
      drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
          'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Acked-by: NJason Cooper <jason@lakedaemon.net>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      31fd8f5b
  6. 03 2月, 2014 1 次提交
  7. 29 1月, 2014 1 次提交
    • A
      dmaengine: mmp_pdma: fix mismerge · 15cec530
      Arnd Bergmann 提交于
      The merge between 2b7f65b1 "mmp_pdma: Style neatening" and
      8010dad5 "dma: add dma_get_any_slave_channel(), for use in of_xlate()"
      caused a build error by leaving obsolete code in place:
      
        mmp_pdma.c: In function 'mmp_pdma_dma_xlate':
        mmp_pdma.c:909:31: error: 'candidate' undeclared
        mmp_pdma.c:912:3: error: label 'retry' used but not defined
        mmp_pdma.c:901:24: warning: unused variable 'c' [-Wunused-variable]
      
      This removes the extraneous lines.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      15cec530
  8. 28 1月, 2014 1 次提交
  9. 26 1月, 2014 2 次提交
  10. 20 1月, 2014 14 次提交
  11. 15 1月, 2014 1 次提交
  12. 13 1月, 2014 1 次提交
  13. 09 1月, 2014 1 次提交
  14. 08 1月, 2014 1 次提交
  15. 03 1月, 2014 1 次提交
    • J
      drivers/dma/ioat/dma.c: check DMA mapping error in ioat_dma_self_test() · 3532e566
      Jiang Liu 提交于
      Check DMA mapping return values in function ioat_dma_self_test() to get
      rid of following warning message.
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 1203 at lib/dma-debug.c:937 check_unmap+0x4c0/0x9a0()
        ioatdma 0000:00:04.0: DMA-API: device driver failed to check map error[device address=0x000000085191b000] [size=2000 bytes] [mapped as single]
        Modules linked in: ioatdma(+) mac_hid wmi acpi_pad lp parport hidd_generic usbhid hid ixgbe isci dca libsas ahci ptp libahci scsi_transport_sas meegaraid_sas pps_core mdio
        CPU: 0 PID: 1203 Comm: systemd-udevd Not tainted 3.13.0-rc4+ #8
        Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRIVTIIN1.86B.0044.L09.1311181644 11/18/2013
        Call Trace:
          dump_stack+0x4d/0x66
          warn_slowpath_common+0x7d/0xa0
          warn_slowpath_fmt+0x4c/0x50
          check_unmap+0x4c0/0x9a0
          debug_dma_unmap_page+0x81/0x90
          ioat_dma_self_test+0x3d2/0x680 [ioatdma]
          ioat3_dma_self_test+0x12/0x30 [ioatdma]
          ioat_probe+0xf4/0x110 [ioatdma]
          ioat3_dma_probe+0x268/0x410 [ioatdma]
          ioat_pci_probe+0x122/0x1b0 [ioatdma]
          local_pci_probe+0x45/0xa0
          pci_device_probe+0xd9/0x130
          driver_probe_device+0x171/0x490
          __driver_attach+0x93/0xa0
          bus_for_each_dev+0x6b/0xb0
          driver_attach+0x1e/0x20
          bus_add_driver+0x1f8/0x2b0
          driver_register+0x81/0x110
          __pci_register_driver+0x60/0x70
          ioat_init_module+0x89/0x1000 [ioatdma]
          do_one_initcall+0xe2/0x250
          load_module+0x2313/0x2a00
          SyS_init_module+0xd9/0x130
          system_call_fastpath+0x1a/0x1f
        ---[ end trace 990c591681d27c31 ]---
        Mapped at:
          debug_dma_map_page+0xbe/0x180
          ioat_dma_self_test+0x1ab/0x680 [ioatdma]
          ioat3_dma_self_test+0x12/0x30 [ioatdma]
          ioat_probe+0xf4/0x110 [ioatdma]
          ioat3_dma_probe+0x268/0x410 [ioatdma]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3532e566
  16. 19 12月, 2013 4 次提交
    • D
      net_dma: mark broken · 77873803
      Dan Williams 提交于
      net_dma can cause data to be copied to a stale mapping if a
      copy-on-write fault occurs during dma.  The application sees missing
      data.
      
      The following trace is triggered by modifying the kernel to WARN if it
      ever triggers copy-on-write on a page that is undergoing dma:
      
       WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
       ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
       Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
       CPU: 24 PID: 2529 Comm: linbug Tainted: G        W    3.13.0-rc1+ #353
        00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
        ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
        ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
       Call Trace:
        [<ffffffff81751041>] dump_stack+0x46/0x58
        [<ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0
        [<ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30
        [<ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50
        [<ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120
        [<ffffffff81154a40>] do_wp_page+0xd0/0x790
        [<ffffffff811582ac>] handle_mm_fault+0x51c/0xde0
        [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
        [<ffffffff8175fc2c>] __do_page_fault+0x19c/0x530
        [<ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40
        [<ffffffff810f3539>] ? trace_clock_local+0x9/0x10
        [<ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310
        [<ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
        [<ffffffff8175ffce>] do_page_fault+0xe/0x10
        [<ffffffff8175c862>] page_fault+0x22/0x30
        [<ffffffff81643991>] ? __kfree_skb+0x51/0xd0
        [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
        [<ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0
        [<ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0
        [<ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0
        [<ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0
        [..]
       ---[ end trace e30e3b01191b7617 ]---
       Mapped at:
        [<ffffffff8139c169>] debug_dma_map_page+0xb9/0x160
        [<ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210
        [<ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0
        [<ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0
        [<ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0:
      
      ...the problem is that the receive path falls back to cpu-copy in
      several locations and this trace is just one of the areas.  A few
      options were considered to fix this:
      
      1/ sync all dma whenever a cpu copy branch is taken
      
      2/ modify the page fault handler to hold off while dma is in-flight
      
      Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
      with cpu-copy.  Option 2 adds checks for behavior that is already documented as
      broken when using get_user_pages().  At a minimum a debug mode is warranted to
      catch and flag these violations of the dma-api vs get_user_pages().
      
      Thanks to David for his reproducer.
      
      Cc: <stable@vger.kernel.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Alexander Duyck <alexander.h.duyck@intel.com>
      Reported-by: NDavid Whipple <whipple@securedatainnovations.ch>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      77873803
    • W
      dma: pl330: ensure DMA descriptors are zero-initialised · 0baf8f6a
      Will Deacon 提交于
      I see the following splat with 3.13-rc1 when attempting to perform DMA:
      
      [  253.004516] Alignment trap: not handling instruction e1902f9f at [<c0204b40>]
      [  253.004583] Unhandled fault: alignment exception (0x221) at 0xdfdfdfd7
      [  253.004646] Internal error: : 221 [#1] PREEMPT SMP ARM
      [  253.004691] Modules linked in: dmatest(+) [last unloaded: dmatest]
      [  253.004798] CPU: 0 PID: 671 Comm: kthreadd Not tainted 3.13.0-rc1+ #2
      [  253.004864] task: df9b0900 ti: df03e000 task.ti: df03e000
      [  253.004937] PC is at dmaengine_unmap_put+0x14/0x34
      [  253.005010] LR is at pl330_tasklet+0x3c8/0x550
      [  253.005087] pc : [<c0204b44>]    lr : [<c0207478>]    psr: a00e0193
      [  253.005087] sp : df03fe48  ip : 00000000  fp : df03bf18
      [  253.005178] r10: bf00e108  r9 : 00000001  r8 : 00000000
      [  253.005245] r7 : df837040  r6 : dfb41800  r5 : df837048  r4 : df837000
      [  253.005316] r3 : dfdfdfcf  r2 : dfb41f80  r1 : df837048  r0 : dfdfdfd7
      [  253.005384] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [  253.005459] Control: 30c5387d  Table: 9fb9ba80  DAC: fffffffd
      [  253.005520] Process kthreadd (pid: 671, stack limit = 0xdf03e248)
      
      This is due to desc->txd.unmap containing garbage (uninitialised memory).
      
      Rather than add another dummy initialisation to _init_desc, instead
      ensure that the descriptors are zero-initialised during allocation and
      remove the dummy, per-field initialisation.
      
      Cc: Andriy Shevchenko <andriy.shevchenko@intel.com>
      Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      0baf8f6a
    • L
      dma: pl08x: allow zero slave channels · 1080411c
      Linus Walleij 提交于
      It might happen that a platform wants to use its DMA engine for
      memcpy only, and then we have zero slave channels to initialize,
      so allow the slave initialization to return zero.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      1080411c
    • E
      dma: edma: Set debug level to debugging messages · 0e772c67
      Ezequiel Garcia 提交于
      The channel allocated/released messages are very spammy and not really
      interesting to users. Change them to "debug" level.
      Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Acked-by: NMatt Porter <mporter@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      0e772c67