1. 03 10月, 2016 2 次提交
  2. 20 9月, 2016 1 次提交
  3. 07 9月, 2016 1 次提交
  4. 23 8月, 2016 1 次提交
  5. 19 8月, 2016 2 次提交
  6. 18 8月, 2016 4 次提交
  7. 13 8月, 2016 8 次提交
  8. 11 8月, 2016 4 次提交
  9. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski 提交于
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  10. 15 7月, 2016 2 次提交
  11. 14 7月, 2016 1 次提交
  12. 15 6月, 2016 1 次提交
    • D
      remoteproc: Fix potential race condition in rproc_add · d2e12e66
      Dave Gerlach 提交于
      rproc_add adds the newly created remoteproc to a list for use by
      rproc_get_by_phandle and then does some additional processing to finish
      adding the remoteproc. This leaves a small window of time in which the
      rproc is available in the list but not yet fully initialized, so if
      another driver comes along and gets a handle to the rproc, it will be
      invalid. Rearrange the code in rproc_add to make sure the rproc is added
      to the list only after it has been successfuly initialized.
      
      Fixes: fec47d86 ("remoteproc: introduce rproc_get_by_phandle API")
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      d2e12e66
  13. 13 5月, 2016 2 次提交
  14. 07 5月, 2016 1 次提交
  15. 29 3月, 2016 1 次提交
  16. 30 1月, 2016 5 次提交
  17. 13 1月, 2016 1 次提交
  18. 26 11月, 2015 2 次提交
    • S
      remoteproc: fix memory leak of remoteproc ida cache layers · f42f79af
      Suman Anna 提交于
      The remoteproc core uses a static ida named rproc_dev_index for
      assigning an automatic index number to a registered remoteproc.
      The ida core may allocate some internal idr cache layers and ida
      bitmap upon any ida allocation, and all these layers are truely
      freed only upon the ida destruction. The rproc_dev_index ida is
      not destroyed at present, leading to a memory leak when using the
      remoteproc core as a module and atleast one rproc device is
      registered and unregistered.
      
      Fix this by invoking ida_destroy() in the remoteproc core module
      exit.
      Signed-off-by: NSuman Anna <s-anna@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      f42f79af
    • A
      remoteproc: avoid stack overflow in debugfs file · 92792e48
      Arnd Bergmann 提交于
      Recent gcc versions warn about reading from a negative offset of
      an on-stack array:
      
      drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
      drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      I don't see anything in sys_write() that prevents us from
      being called with a zero 'count' argument, so we should
      add an extra check in rproc_recovery_write() to prevent the
      access and avoid the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 2e37abb8 ("remoteproc: create a 'recovery' debugfs entry")
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      92792e48