1. 09 9月, 2015 1 次提交
    • V
      mm: rename alloc_pages_exact_node() to __alloc_pages_node() · 96db800f
      Vlastimil Babka 提交于
      alloc_pages_exact_node() was introduced in commit 6484eb3e ("page
      allocator: do not check NUMA node ID when the caller knows the node is
      valid") as an optimized variant of alloc_pages_node(), that doesn't
      fallback to current node for nid == NUMA_NO_NODE.  Unfortunately the
      name of the function can easily suggest that the allocation is
      restricted to the given node and fails otherwise.  In truth, the node is
      only preferred, unless __GFP_THISNODE is passed among the gfp flags.
      
      The misleading name has lead to mistakes in the past, see for example
      commits 5265047a ("mm, thp: really limit transparent hugepage
      allocation to local node") and b360edb4 ("mm, mempolicy:
      migrate_to_node should only migrate to node").
      
      Another issue with the name is that there's a family of
      alloc_pages_exact*() functions where 'exact' means exact size (instead
      of page order), which leads to more confusion.
      
      To prevent further mistakes, this patch effectively renames
      alloc_pages_exact_node() to __alloc_pages_node() to better convey that
      it's an optimized variant of alloc_pages_node() not intended for general
      usage.  Both functions get described in comments.
      
      It has been also considered to really provide a convenience function for
      allocations restricted to a node, but the major opinion seems to be that
      __GFP_THISNODE already provides that functionality and we shouldn't
      duplicate the API needlessly.  The number of users would be small
      anyway.
      
      Existing callers of alloc_pages_exact_node() are simply converted to
      call __alloc_pages_node(), with the exception of sba_alloc_coherent()
      which open-codes the check for NUMA_NO_NODE, so it is converted to use
      alloc_pages_node() instead.  This means it no longer performs some
      VM_BUG_ON checks, and since the current check for nid in
      alloc_pages_node() uses a 'nid < 0' comparison (which includes
      NUMA_NO_NODE), it may hide wrong values which would be previously
      exposed.
      
      Both differences will be rectified by the next patch.
      
      To sum up, this patch makes no functional changes, except temporarily
      hiding potentially buggy callers.  Restricting the checks in
      alloc_pages_node() is left for the next patch which can in turn expose
      more existing buggy callers.
      Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NRobin Holt <robinmholt@gmail.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Cliff Whickman <cpw@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96db800f
  2. 07 8月, 2015 1 次提交
  3. 03 8月, 2015 1 次提交
    • A
      locking, arch: use WRITE_ONCE()/READ_ONCE() in smp_store_release()/smp_load_acquire() · 76695af2
      Andrey Konovalov 提交于
      Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
      with WRITE_ONCE() and READ_ONCE() on x86, arm, arm64, ia64, metag, mips,
      powerpc, s390, sparc and asm-generic since ACCESS_ONCE() does not work
      reliably on non-scalar types.
      
      WRITE_ONCE() and READ_ONCE() were introduced in the following commits:
      
        230fa253 ("kernel: Provide READ_ONCE and ASSIGN_ONCE")
        43239cbe ("kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)")
      Signed-off-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NDavidlohr Bueso <dbueso@suse.de>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Alexander Duyck <alexander.h.duyck@redhat.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arch@vger.kernel.org
      Link: http://lkml.kernel.org/r/1438528264-714-1-git-send-email-andreyknvl@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      76695af2
  4. 27 7月, 2015 4 次提交
  5. 23 7月, 2015 1 次提交
    • L
      PCI: Call pci_read_bridge_bases() from core instead of arch code · dff22d20
      Lorenzo Pieralisi 提交于
      When we scan a PCI bus, we read PCI-PCI bridge window registers with
      pci_read_bridge_bases() so we can validate the resource hierarchy.  Most
      architectures call pci_read_bridge_bases() from pcibios_fixup_bus(), but
      PCI-PCI bridges are not arch-specific, so this doesn't need to be in
      arch-specific code.
      
      Call pci_read_bridge_bases() directly from the PCI core instead of from
      arch code.
      
      For alpha and mips, we now call pci_read_bridge_bases() always; previously
      we only called it if PCI_PROBE_ONLY was set.
      
      [bhelgaas: changelog]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Ralf Baechle <ralf@linux-mips.org>
      CC: James E.J. Bottomley <jejb@parisc-linux.org>
      CC: Michael Ellerman <mpe@ellerman.id.au>
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Richard Henderson <rth@twiddle.net>
      CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: David Howells <dhowells@redhat.com>
      CC: Russell King <linux@arm.linux.org.uk>
      CC: Tony Luck <tony.luck@intel.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Guenter Roeck <linux@roeck-us.net>
      CC: Michal Simek <monstr@monstr.eu>
      CC: Chris Zankel <chris@zankel.net>
      dff22d20
  6. 18 7月, 2015 1 次提交
  7. 17 7月, 2015 1 次提交
  8. 03 7月, 2015 1 次提交
    • T
      [IA64] Drop debug test/printk that some special pages are marked reserved · 43c518d1
      Tony Luck 提交于
      In commit 92923ca3 "mm: meminit: only set page reserved in the memblock region"
      we dropped setting the reserved bits for all pages. This results in some warnings
      on ia64:
      
      put_kernel_page: page at 0xe000000005588000 not in reserved memory
      put_kernel_page: page at 0xe000000005588000 not in reserved memory
      put_kernel_page: page at 0xe000000005580000 not in reserved memory
      put_kernel_page: page at 0xe000000005580000 not in reserved memory
      put_kernel_page: page at 0xe000000005580000 not in reserved memory
      put_kernel_page: page at 0xe000000005580000 not in reserved memory
      
      the two different pages match up with two objects from the loaded kernel
      that get mapped by arch/ia64/mm/init.c:setup_gate()
      
      a000000101588000 D __start_gate_section
      a000000101580000 D empty_zero_page
      
      In a discussion with Mel Gorman:
        http://lkml.kernel.org/r/20150526102219.GB13750%40suse.de
      he suggested that while the preferred approach might be to
      set the reserved bit for these pages, it would also be OK
      to just drop the test:
         "as it's a debugging check that is ia-64 specific"
      
      After hunting around a bit and failin to find a good place to mark these
      pages as reserved - I decided to just delete the test.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      43c518d1
  9. 01 7月, 2015 1 次提交
  10. 26 6月, 2015 1 次提交
  11. 25 6月, 2015 3 次提交
    • Z
      mm/hugetlb: reduce arch dependent code about hugetlb_prefault_arch_hook · a67a31fa
      Zhang Zhen 提交于
      Currently we have many duplicates in definitions of
      hugetlb_prefault_arch_hook.  In all architectures this function is empty.
      Signed-off-by: NZhang Zhen <zhenzhang.zhang@huawei.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a67a31fa
    • L
      mm: new mm hook framework · 2ae416b1
      Laurent Dufour 提交于
      CRIU is recreating the process memory layout by remapping the checkpointee
      memory area on top of the current process (criu).  This includes remapping
      the vDSO to the place it has at checkpoint time.
      
      However some architectures like powerpc are keeping a reference to the
      vDSO base address to build the signal return stack frame by calling the
      vDSO sigreturn service.  So once the vDSO has been moved, this reference
      is no more valid and the signal frame built later are not usable.
      
      This patch serie is introducing a new mm hook framework, and a new
      arch_remap hook which is called when mremap is done and the mm lock still
      hold.  The next patch is adding the vDSO remap and unmap tracking to the
      powerpc architecture.
      
      This patch (of 3):
      
      This patch introduces a new set of header file to manage mm hooks:
      - per architecture empty header file (arch/x/include/asm/mm-arch-hooks.h)
      - a generic header (include/linux/mm-arch-hooks.h)
      
      The architecture which need to overwrite a hook as to redefine it in its
      header file, while architecture which doesn't need have nothing to do.
      
      The default hooks are defined in the generic header and are used in the
      case the architecture is not defining it.
      
      In a next step, mm hooks defined in include/asm-generic/mm_hooks.h should
      be moved here.
      Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Suggested-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2ae416b1
    • Z
      mm/hugetlb: reduce arch dependent code about huge_pmd_unshare · e81f2d22
      Zhang Zhen 提交于
      Currently we have many duplicates in definitions of huge_pmd_unshare.  In
      all architectures this function just returns 0 when
      CONFIG_ARCH_WANT_HUGE_PMD_SHARE is N.
      
      This patch puts the default implementation in mm/hugetlb.c and lets these
      architectures use the common code.
      Signed-off-by: NZhang Zhen <zhenzhang.zhang@huawei.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: James Yang <James.Yang@freescale.com>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e81f2d22
  12. 17 6月, 2015 2 次提交
    • P
      ia64: don't use module_init in non-modular sim/simscsi.c code · 2a177fd1
      Paul Gortmaker 提交于
      The simscsi.o is built for HP_SIMSCSI -- which is bool, and hence
      this code is either present or absent.  It will never be modular,
      so using module_init as an alias for __initcall can be somewhat
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      And since it can't be modular, we remove all the __exitcall
      stuff related to module_exit() -- it is dead code that won't
      ever be executed.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      2a177fd1
    • P
      ia64: don't use module_init for non-modular core kernel/mca.c code · 2e21fa2d
      Paul Gortmaker 提交于
      The mca.c code is always built in.  It will never be modular,
      so using module_init as an alias for __initcall is rather
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      2e21fa2d
  13. 16 6月, 2015 2 次提交
  14. 11 6月, 2015 1 次提交
    • L
      ia64: remove paravirt code · e55645ec
      Luis R. Rodriguez 提交于
      All the ia64 pvops code is now dead code since both
      xen and kvm support have been ripped out [0] [1]. Just
      that no one had troubled to rip this stuff out. The only
      useful remaining pieces were the old pvops docs but that
      was recently also generalized and moved out from ia64 [2].
      
      This has been run time tested on an ia64 Madison system.
      
      [0] 003f7de6 "KVM: ia64: remove" since v3.19-rc1
      [1] d52eefb4 "ia64/xen: Remove Xen support for ia64" since v3.14-rc1
      [2] "virtual: Documentation: simplify and generalize paravirt_ops.txt"
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      e55645ec
  15. 08 6月, 2015 2 次提交
  16. 03 6月, 2015 1 次提交
  17. 28 5月, 2015 2 次提交
    • D
      e820, efi: add ACPI 6.0 persistent memory types · ad5fb870
      Dan Williams 提交于
      ACPI 6.0 formalizes e820-type-7 and efi-type-14 as persistent memory.
      Mark it "reserved" and allow it to be claimed by a persistent memory
      device driver.
      
      This definition is in addition to the Linux kernel's existing type-12
      definition that was recently added in support of shipping platforms with
      NVDIMM support that predate ACPI 6.0 (which now classifies type-12 as
      OEM reserved).
      
      Note, /proc/iomem can be consulted for differentiating legacy
      "Persistent Memory (legacy)" E820_PRAM vs standard "Persistent Memory"
      E820_PMEM.
      
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ad5fb870
    • R
      PCI / ACPI: Do not set ACPI companions for host bridges with parents · dc4fdaf0
      Rafael J. Wysocki 提交于
      Commit 97badf87 (device property: Make it possible to use
      secondary firmware nodes) uncovered a bug in the x86 (and ia64) PCI
      host bridge initialization code that assumes bridge->bus->sysdata
      to always point to a struct pci_sysdata object which need not be
      the case (in particular, the Xen PCI frontend driver sets it to point
      to a different data type).  If it is not the case, an incorrect
      pointer (or a piece of data that is not a pointer at all) will be
      passed to ACPI_COMPANION_SET() and that may cause interesting
      breakage to happen going forward.
      
      To work around this problem use the observation that the ACPI
      host bridge initialization always passes NULL as parent to
      pci_create_root_bus(), so if pcibios_root_bridge_prepare() sees
      a non-NULL parent of the bridge, it should not attempt to set
      an ACPI companion for it, because that means that
      pci_create_root_bus() has been called by someone else.
      
      Fixes: 97badf87 (device property: Make it possible to use secondary firmware nodes)
      Reported-and-tested-by: NSander Eikelenboom <linux@eikelenboom.it>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      dc4fdaf0
  18. 27 5月, 2015 1 次提交
  19. 19 5月, 2015 4 次提交
  20. 13 5月, 2015 1 次提交
  21. 06 5月, 2015 1 次提交
  22. 24 4月, 2015 1 次提交
    • J
      iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit · 34742db8
      Jiang Liu 提交于
      Refine the interfaces to create IRQ for DMAR unit. It's a preparation
      for converting DMAR IRQ to hierarchical irqdomain on x86.
      
      It also moves dmar_alloc_hwirq()/dmar_free_hwirq() from irq_remapping.h
      to dmar.h. They are not irq_remapping specific.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Cohen <david.a.cohen@linux.intel.com>
      Cc: Sander Eikelenboom <linux@eikelenboom.it>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: iommu@lists.linux-foundation.org
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Link: http://lkml.kernel.org/r/1428905519-23704-20-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      34742db8
  23. 22 4月, 2015 1 次提交
    • B
      ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows · 9fbbda5c
      Bjorn Helgaas 提交于
      Prior to c770cb4c ("PCI: Mark invalid BARs as unassigned"), if we tried
      to claim a PCI BAR but could not find an upstream bridge window that
      matched it, we complained but still allowed the device to be enabled.
      
      c770cb4c broke devices that previously worked (mptsas and igb in the
      case Tony reported, but it could be any devices) because it marks those
      BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and
      return failure:
      
        igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned
        igb: probe of 0000:81:00.0 failed with error -22
      
      The underlying cause is an ACPI Address Space Descriptor for a PCI host
      bridge window that is marked as "consumer".  This is a firmware defect:
      resources that are produced on the downstream side of a bridge should be
      marked "producer".  But rejecting these BARs that we previously allowed is
      a functionality regression, and firmware has not used the producer/consumer
      bit consistently, so we can't rely on it anyway.
      
      Stop checking the producer/consumer bit, and assume all bridge Address
      Space Descriptors are for bridge windows.
      
      Note that this change does not affect I/O Port or Fixed Location I/O Port
      Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config
      access range.  That range is a "consumer" range and should not be treated
      as a window.
      
      Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961Reported-and-tested-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9fbbda5c
  24. 16 4月, 2015 1 次提交
  25. 15 4月, 2015 1 次提交
  26. 13 4月, 2015 2 次提交
  27. 02 4月, 2015 1 次提交