1. 10 Aug, 2016 1 commit
  2. 09 Aug, 2016 2 commits
  3. 04 Aug, 2016 1 commit
    • Krzysztof Kozlowski's avatar
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski authored
      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
          identifier f, attrs;
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          identifier r.f;
          - NULL
          + 0
          // Options: --all-includes
          virtual patch
          virtual context
          identifier f, attrs;
          type t;
          t f(..., struct dma_attrs *attrs);
          identifier r.f;
          - NULL
          + 0
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarHans-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: default avatarBart 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: default avatarBjorn 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 27 Jul, 2016 1 commit
    • Linus Torvalds's avatar
      Add braces to avoid "ambiguous ‘else’" compiler warnings · 194dc870
      Linus Torvalds authored
      Some of our "for_each_xyz()" macro constructs make gcc unhappy about
      lack of braces around if-statements inside or outside the loop, because
      the loop construct itself has a "if-then-else" statement inside of it.
      The resulting warnings look something like this:
        drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
        drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
           if (ctx != dev_priv->kernel_context)
      even if the code itself is fine.
      Since the warning is fairly easy to avoid by adding a braces around the
      if-statement near the for_each_xyz() construct, do so, rather than
      disabling the otherwise potentially useful warning.
      (The if-then-else statements used in the "for_each_xyz()" constructs are
      designed to be inherently safe even with no braces, but in this case
      it's quite understandable that gcc isn't really able to tell that).
      This finally leaves the standard "allmodconfig" build with just a
      handful of remaining warnings, so new and valid warnings hopefully will
      stand out.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 26 Jul, 2016 3 commits
  6. 14 Jul, 2016 6 commits
  7. 13 Jul, 2016 19 commits
  8. 06 Jul, 2016 2 commits
  9. 04 Jul, 2016 1 commit
    • Aaron Campbell's avatar
      iommu/vt-d: Fix infinite loop in free_all_cpu_cached_iovas · 0caa7616
      Aaron Campbell authored
      Per VT-d spec Section 10.4.2 ("Capability Register"), the maximum
      number of possible domains is 64K; indeed this is the maximum value
      that the cap_ndoms() macro will expand to.  Since the value 65536
      will not fix in a u16, the 'did' variable must be promoted to an
      int, otherwise the test for < 65536 will always be true and the
      loop will never end.
      The symptom, in my case, was a hung machine during suspend.
      Fixes: 3bd4f911 ("iommu/vt-d: Fix overflow of iommu->domains array")
      Signed-off-by: default avatarAaron Campbell <aaron@monkey.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
  10. 01 Jul, 2016 2 commits
    • Will Deacon's avatar
      iommu/io-pgtable-arm: Fix iova_to_phys for block entries · 7c6d90e2
      Will Deacon authored
      The implementation of iova_to_phys for the long-descriptor ARM
      io-pgtable code always masks with the granule size when inserting the
      low virtual address bits into the physical address determined from the
      page tables. In cases where the leaf entry is found before the final
      level of table (i.e. due to a block mapping), this results in rounding
      down to the bottom page of the block mapping. Consequently, the physical
      address range batching in the vfio_unmap_unpin is defeated and we end
      up taking the long way home.
      This patch fixes the problem by masking the virtual address with the
      appropriate mask for the level at which the leaf descriptor is located.
      The short-descriptor code already gets this right, so no change is
      needed there.
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Tested-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    • Wei Chen's avatar
      iommu/arm-smmu: request pcie devices to enable ACS · 112c898b
      Wei Chen authored
      The PCIe ACS capability will affect the layout of iommu groups.
      Generally speaking, if the path from root port to the PCIe device
      is ACS enabled, the iommu will create a single iommu group for this
      PCIe device. If all PCIe devices on the path are ACS enabled then
      Linux can determine this path is ACS enabled.
      Linux use two PCIe configuration registers to determine the ACS
      status of PCIe devices:
      ACS Capability Register and ACS Control Register.
      The first register is used to check the implementation of ACS function
      of a PCIe device, the second register is used to check the enable status
      of ACS function. If one PCIe device has implemented and enabled the ACS
      function then Linux will determine this PCIe device enabled ACS.
      From the Chapter:6.12 of PCI Express Base Specification Revision 3.1a,
      we can find that when a PCIe device implements ACS function, the enable
      status is set to disabled by default and can be enabled by ACS-aware
      ACS will affect the iommu groups topology, so, the iommu driver is
      ACS-aware software. This patch adds a call to pci_request_acs() to the
      arm-smmu driver to enable the ACS function in PCIe devices that support
      it, when they get probed.
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarEric Auger <eric.auger@redhat.com>
      Signed-off-by: default avatarWei Chen <Wei.Chen@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  11. 27 Jun, 2016 2 commits