1. 19 Apr, 2013 8 commits
  2. 18 Apr, 2013 5 commits
  3. 17 Apr, 2013 25 commits
  4. 16 Apr, 2013 2 commits
    • Marcelo Tosatti's avatar
      Merge branch 'kvm-arm-fixes-3.9' of git://github.com/columbia/linux-kvm-arm · 23125c40
      Marcelo Tosatti authored
      * 'kvm-arm-fixes-3.9' of git://github.com/columbia/linux-kvm-arm:
        ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write
        ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reporting
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      23125c40
    • Linus Torvalds's avatar
      vm: add vm_iomap_memory() helper function · b4cbb197
      Linus Torvalds authored
      Various drivers end up replicating the code to mmap() their memory
      buffers into user space, and our core memory remapping function may be
      very flexible but it is unnecessarily complicated for the common cases
      to use.
      
      Our internal VM uses pfn's ("page frame numbers") which simplifies
      things for the VM, and allows us to pass physical addresses around in a
      denser and more efficient format than passing a "phys_addr_t" around,
      and having to shift it up and down by the page size.  But it just means
      that drivers end up doing that shifting instead at the interface level.
      
      It also means that drivers end up mucking around with internal VM things
      like the vma details (vm_pgoff, vm_start/end) way more than they really
      need to.
      
      So this just exports a function to map a certain physical memory range
      into user space (using a phys_addr_t based interface that is much more
      natural for a driver) and hides all the complexity from the driver.
      Some drivers will still end up tweaking the vm_page_prot details for
      things like prefetching or cacheability etc, but that's actually
      relevant to the driver, rather than caring about what the page offset of
      the mapping is into the particular IO memory region.
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b4cbb197