1. 16 May, 2016 1 commit
  2. 12 Mar, 2016 1 commit
  3. 09 Mar, 2016 1 commit
    • Toshi Kani's avatar
      resource: Add remove_resource interface · ff3cc952
      Toshi Kani authored
      insert_resource() and insert_resource_conflict() are called
      by resource producers to insert a new resource.  When there
      is any conflict, they move conflicting resources down to the
      children of the new resource.  There is no destructor of these
      interfaces, however.
      
      Add remove_resource(), which removes a resource previously
      inserted by insert_resource() or insert_resource_conflict(),
      and moves the children up to where they were before.
      
      __release_resource() is changed to have @release_child, so
      that this function can be used for remove_resource() as well.
      
      Also add comments to clarify that these functions are intended
      for producers of resources to avoid any confusion with
      request/release_resource() for consumers.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      ff3cc952
  4. 08 Mar, 2016 1 commit
    • Bjorn Helgaas's avatar
      PCI: Set ROM shadow location in arch code, not in PCI core · 0c0e0736
      Bjorn Helgaas authored
      IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
      RAM.  The existence of such a copy and its location are arch-specific.
      Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
      0xC0000-0xDFFFF location was hard-coded into the PCI core.
      
      If we're using a shadow copy in RAM, disable the ROM BAR and release the
      address space it was consuming.  Move the location information from the PCI
      core to the arch code that sets IORESOURCE_ROM_SHADOW.  Save the location
      of the RAM copy in the struct resource for PCI_ROM_RESOURCE.
      
      After this change, pci_map_rom() will call pci_assign_resource() and
      pci_enable_rom() for these IORESOURCE_ROM_SHADOW resources, which we did
      not do before.  This is safe because:
      
        - pci_assign_resource() will do nothing because the resource is marked
          IORESOURCE_PCI_FIXED, which means we can't move it, and
      
        - pci_enable_rom() will not turn on the ROM BAR's enable bit because the
          resource is marked IORESOURCE_ROM_SHADOW, which means it is in RAM
          rather than in PCI memory space.
      
      Storing the location in the struct resource means "lspci" will show the
      shadow location, not the value from the ROM BAR.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0c0e0736
  5. 30 Jan, 2016 4 commits
    • Toshi Kani's avatar
      resource: Kill walk_iomem_res() · a8fc4253
      Toshi Kani authored
      walk_iomem_res_desc() replaced walk_iomem_res() and there is no
      caller to walk_iomem_res() any more. Kill it. Also remove @name
      from find_next_iomem_res() as it is no longer used.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Jakub Sitnicki <jsitnicki@gmail.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Link: http://lkml.kernel.org/r/1453841853-11383-17-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a8fc4253
    • Toshi Kani's avatar
      resource: Add walk_iomem_res_desc() · 3f33647c
      Toshi Kani authored
      Add a new interface, walk_iomem_res_desc(), which walks through
      the iomem table by identifying a target with @flags and @desc.
      This interface provides the same functionality as
      walk_iomem_res(), but does not use strcmp() to @name for better
      efficiency.
      
      walk_iomem_res() is deprecated and will be removed in a later
      patch.
      Requested-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      [ Fixup comments. ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Jakub Sitnicki <jsitnicki@gmail.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Link: http://lkml.kernel.org/r/1453841853-11383-14-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3f33647c
    • Toshi Kani's avatar
      resource: Add I/O resource descriptor · 43ee493b
      Toshi Kani authored
      walk_iomem_res() and region_intersects() still need to use
      strcmp() for searching a resource entry by @name in the iomem
      table.
      
      This patch introduces I/O resource descriptor 'desc' in struct
      resource for the iomem search interfaces. Drivers can assign
      their unique descriptor to a range when they support the search
      interfaces.
      
      Otherwise, 'desc' is set to IORES_DESC_NONE (0). This avoids
      changing most of the drivers as they typically allocate resource
      entries statically, or by calling alloc_resource(), kzalloc(),
      or alloc_bootmem_low(), which set the field to zero by default.
      A later patch will address some drivers that use kmalloc()
      without zero'ing the field.
      
      Also change release_mem_region_adjustable() to set 'desc' when
      its resource entry gets separated. Other resource interfaces are
      also changed to initialize 'desc' explicitly although
      alloc_resource() sets it to 0.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jakub Sitnicki <jsitnicki@gmail.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Link: http://lkml.kernel.org/r/1453841853-11383-4-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      43ee493b
    • Toshi Kani's avatar
      resource: Add System RAM resource type · 9babd5c8
      Toshi Kani authored
      The IORESOURCE_MEM I/O resource type is used for all types of
      memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
      Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
      reserved, and so on.
      
      This requires walk_system_ram_range(), walk_system_ram_res(),
      and region_intersects() to use strcmp() against string "System
      RAM" to search for System RAM ranges in the iomem table, which
      is inefficient. __ioremap_caller() and reserve_memtype() on x86,
      for instance, call walk_system_ram_range() for every request to
      check if a given range is in System RAM ranges.
      
      However, adding a new I/O resource type for System RAM is not a
      viable option, see [1]. There are approx. 3800 references to
      IORESOURCE_MEM in the kernel/drivers, which makes it very
      difficult to distinguish their usages between new type and
      IORESOURCE_MEM.
      
      The I/O resource types are also used by the PNP subsystem.
      Therefore, introduce an extended I/O resource type,
      IORESOURCE_SYSTEM_RAM, which consists of IORESOURCE_MEM and a
      new modifier flag IORESOURCE_SYSRAM, see [2].
      
      To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' still
      working for System RAM, resource_ext_type() is added for
      extracting extended type bits.
      
      Link[1]: http://lkml.kernel.org/r/1449168859.9855.54.camel@hpe.com
      Link[2]: http://lkml.kernel.org/r/CA+55aFy4WQrWexC4u2LxX9Mw2NVoznw7p3Yh=iF4Xtf7zKWnRw@mail.gmail.comSigned-off-by: default avatarToshi Kani <toshi.kani@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Jakub Sitnicki <jsitnicki@gmail.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-mm <linux-mm@kvack.org>
      Link: http://lkml.kernel.org/r/1453841853-11383-2-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      9babd5c8
  6. 16 Oct, 2015 1 commit
  7. 15 Apr, 2015 1 commit
  8. 04 Sep, 2014 1 commit
  9. 08 Aug, 2014 1 commit
    • Vivek Goyal's avatar
      resource: provide new functions to walk through resources · 8c86e70a
      Vivek Goyal authored
      I have added two more functions to walk through resources.
      
      Currently walk_system_ram_range() deals with pfn and /proc/iomem can
      contain partial pages.  By dealing in pfn, callback function loses the
      info that last page of a memory range is a partial page and not the full
      page.  So I implemented walk_system_ram_res() which returns u64 values to
      callback functions and now it properly return start and end address.
      
      walk_system_ram_range() uses find_next_system_ram() to find the next ram
      resource.  This in turn only travels through siblings of top level child
      and does not travers through all the nodes of the resoruce tree.  I also
      need another function where I can walk through all the resources, for
      example figure out where "GART" aperture is.  Figure out where ACPI memory
      is.
      
      So I wrote another function walk_iomem_res() which walks through all
      /proc/iomem resources and returns matches as asked by caller.  Caller can
      specify "name" of resource, start and end and flags.
      
      Got rid of find_next_system_ram_res() and instead implemented more generic
      find_next_iomem_res() which can be used to traverse top level children
      only based on an argument.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8c86e70a
  10. 26 Feb, 2014 2 commits
    • Bjorn Helgaas's avatar
      vsprintf: Add support for IORESOURCE_UNSET in %pR · d19cb803
      Bjorn Helgaas authored
      Sometimes we have a struct resource where we know the type (MEM/IO/etc.)
      and the size, but we haven't assigned address space for it.  The
      IORESOURCE_UNSET flag is a way to indicate this situation.  For these
      "unset" resources, the start address is meaningless, so print only the
      size, e.g.,
      
        - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit]
        + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit]
      
      For %pr (printing with raw flags), we still print the address range,
      because %pr is mostly used for debugging anyway.
      
      Thanks to Fengguang Wu <fengguang.wu@intel.com> for suggesting
      resource_size().
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      d19cb803
    • Bjorn Helgaas's avatar
      resource: Add resource_contains() · 5edb93b8
      Bjorn Helgaas authored
      We have two identical copies of resource_contains() already, and more
      places that could use it.  This moves it to ioport.h where it can be
      shared.
      
      resource_contains(struct resource *r1, struct resource *r2) returns true
      iff r1 and r2 are the same type (most callers already checked this
      separately) and the r1 address range completely contains r2.
      
      In addition, the new resource_contains() checks that both r1 and r2 have
      addresses assigned to them.  If a resource is IORESOURCE_UNSET, it doesn't
      have a valid address and can't contain or be contained by another resource.
      Some callers already check this or for res->start.
      
      No functional change.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      5edb93b8
  11. 29 Apr, 2013 1 commit
    • Toshi Kani's avatar
      resource: add release_mem_region_adjustable() · 825f787b
      Toshi Kani authored
      Add release_mem_region_adjustable(), which releases a requested region
      from a currently busy memory resource.  This interface adjusts the
      matched memory resource accordingly even if the requested region does
      not match exactly but still fits into.
      
      This new interface is intended for memory hot-delete.  During bootup,
      memory resources are inserted from the boot descriptor table, such as
      EFI Memory Table and e820.  Each memory resource entry usually covers
      the whole contigous memory range.  Memory hot-delete request, on the
      other hand, may target to a particular range of memory resource, and its
      size can be much smaller than the whole contiguous memory.  Since the
      existing release interfaces like __release_region() require a requested
      region to be exactly matched to a resource entry, they do not allow a
      partial resource to be released.
      
      This new interface is restrictive (i.e.  release under certain
      conditions), which is consistent with other release interfaces,
      __release_region() and __release_resource().  Additional release
      conditions, such as an overlapping region to a resource entry, can be
      supported after they are confirmed as valid cases.
      
      There is no change to the existing interfaces since their restriction is
      valid for I/O resources.
      
      [akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
      [akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
      [akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Reviewed-by: default avatarRam Pai <linuxram@us.ibm.com>
      Cc: T Makphaibulchoke <tmac@hp.com>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      825f787b
  12. 11 Sep, 2012 2 commits
  13. 07 May, 2012 1 commit
  14. 14 Feb, 2012 1 commit
  15. 30 Jul, 2011 1 commit
  16. 25 Jul, 2011 1 commit
  17. 17 Dec, 2010 2 commits
  18. 26 Oct, 2010 1 commit
    • Bjorn Helgaas's avatar
      resources: support allocating space within a region from the top down · e7f8567d
      Bjorn Helgaas authored
      Allocate space from the top of a region first, then work downward,
      if an architecture desires this.
      
      When we allocate space from a resource, we look for gaps between children
      of the resource.  Previously, we always looked at gaps from the bottom up.
      For example, given this:
      
          [mem 0xbff00000-0xf7ffffff] PCI Bus 0000:00
            [mem 0xbff00000-0xbfffffff] gap -- available
            [mem 0xc0000000-0xdfffffff] PCI Bus 0000:02
            [mem 0xe0000000-0xf7ffffff] gap -- available
      
      we attempted to allocate from the [mem 0xbff00000-0xbfffffff] gap first,
      then the [mem 0xe0000000-0xf7ffffff] gap.
      
      With this patch an architecture can choose to allocate from the top gap
      [mem 0xe0000000-0xf7ffffff] first.
      
      We can't do this across the board because iomem_resource.end is initialized
      to 0xffffffff_ffffffff on 64-bit architectures, and most machines can't
      address the entire 64-bit physical address space.  Therefore, we only
      allocate top-down if the arch requests it by clearing
      "resource_alloc_from_bottom".
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      e7f8567d
  19. 11 May, 2010 1 commit
    • Alan Cox's avatar
      resource: shared I/O region support · 8b6d043b
      Alan Cox authored
      SuperIO devices share regions and use lock/unlock operations to chip
      select.  We therefore need to be able to request a resource and wait for
      it to be freed by whichever other SuperIO device currently hogs it.
      Right now you have to poll which is horrible.
      
      Add a MUXED field to IO port resources. If the MUXED field is set on the
      resource and on the request (via request_muxed_region) then we block
      until the previous owner of the muxed resource releases their region.
      
      This allows us to implement proper resource sharing and locking for
      superio chips using code of the form
      
      enable_my_superio_dev() {
      	request_muxed_region(0x44, 0x02, "superio:watchdog");
      	outb() ..sequence to enable chip
      }
      
      disable_my_superio_dev() {
      	outb() .. sequence of disable chip
      	release_region(0x44, 0x02);
      }
      Signed-off-by: default avatarGiel van Schijndel <me@mortis.eu>
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      8b6d043b
  20. 23 Mar, 2010 1 commit
  21. 14 Mar, 2010 3 commits
  22. 22 Feb, 2010 3 commits
  23. 01 Feb, 2010 2 commits
  24. 16 Dec, 2009 1 commit
  25. 23 Sep, 2009 1 commit
    • KAMEZAWA Hiroyuki's avatar
      walk system ram range · 908eedc6
      KAMEZAWA Hiroyuki authored
      Originally, walk_memory_resource() was introduced to traverse all memory
      of "System RAM" for detecting memory hotplug/unplug range.  For doing so,
      flags of IORESOUCE_MEM|IORESOURCE_BUSY was used and this was enough for
      memory hotplug.
      
      But for using other purpose, /proc/kcore, this may includes some firmware
      area marked as IORESOURCE_BUSY | IORESOUCE_MEM.  This patch makes the
      check strict to find out busy "System RAM".
      
      Note: PPC64 keeps their own walk_memory_resouce(), which walk through
      ppc64's lmb informaton.  Because old kclist_add() is called per lmb, this
      patch makes no difference in behavior, finally.
      
      And this patch removes CONFIG_MEMORY_HOTPLUG check from this function.
      Because pfn_valid() just show "there is memmap or not* and cannot be used
      for "there is physical memory or not", this function is useful in generic
      to scan physical memory range.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Cc: Américo Wang <xiyou.wangcong@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Roland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      908eedc6
  26. 11 Jun, 2009 1 commit
  27. 15 Jan, 2009 1 commit
  28. 07 Jan, 2009 1 commit
    • Arjan van de Ven's avatar
      resource: allow MMIO exclusivity for device drivers · e8de1481
      Arjan van de Ven authored
      Device drivers that use pci_request_regions() (and similar APIs) have a
      reasonable expectation that they are the only ones accessing their device.
      As part of the e1000e hunt, we were afraid that some userland (X or some
      bootsplash stuff) was mapping the MMIO region that the driver thought it
      had exclusively via /dev/mem or via various sysfs resource mappings.
      
      This patch adds the option for device drivers to cause their reserved
      regions to the "banned from /dev/mem use" list, so now both kernel memory
      and device-exclusive MMIO regions are banned.
      NOTE: This is only active when CONFIG_STRICT_DEVMEM is set.
      
      In addition to the config option, a kernel parameter iomem=relaxed is
      provided for the cases where developers want to diagnose, in the field,
      drivers issues from userspace.
      Reviewed-by: default avatarMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      e8de1481
  29. 16 Oct, 2008 1 commit