1. 08 8月, 2014 1 次提交
    • J
      x86, irq, PCI: Keep IRQ assignment for PCI devices during suspend/hibernation · 3eec5952
      Jiang Liu 提交于
      Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
      We need to keep IRQ assignment for PCI devices during suspend/hibernation,
      otherwise it may cause failure of suspend/hibernation due to:
      1) Device driver calls pci_enable_device() to allocate an IRQ number
         and register interrupt handler on the returned IRQ.
      2) Device driver's suspend callback calls pci_disable_device() and
         release assigned IRQ in turn.
      3) Device driver's resume callback calls pci_enable_device() to
         allocate IRQ number again. A different IRQ number may be assigned
         by IOAPIC driver this time.
      4) Now the hardware delivers interrupt to the new IRQ but interrupt
         handler is still registered against the old IRQ, so it breaks
         suspend/hibernation.
      
      To fix this issue, we keep IRQ assignment during suspend/hibernation.
      Flag pci_dev.dev.power.is_prepared is used to detect that
      pci_disable_device() is called during suspend/hibernation.
      Reported-and-Tested-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/1407478071-29399-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      3eec5952
  2. 17 7月, 2014 1 次提交
    • C
      x86: don't exclude low BIOS area when allocating address space for non-PCI cards · cbace46a
      Christoph Schulz 提交于
      Commit 30919b0b ("x86: avoid low BIOS area when allocating address
      space") moved the test for resource allocations that fall within the first
      1MB of address space from the PCI-specific path to a generic path, such
      that all resource allocations will avoid this area.  However, this breaks
      ISA cards which need to allocate a memory region within the first 1MB.  An
      example is the i82365 PCMCIA controller and derivatives like the Ricoh
      RF5C296/396 which map part of the PCMCIA socket memory address space into
      the first 1MB of system memory address space.  They do not work anymore as
      no usable memory region exists due to this change:
      
        Intel ISA PCIC probe: Ricoh RF5C296/396 ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets
        host opts [0]: none
        host opts [1]: none
        ISA irqs (scanned) = 3,4,5,9,10 status change on irq 10
        pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1
        pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff
        pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
        pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0d0000-0x0dffff: clean.
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x0e0000-0x0effff: clean.
        pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: clean.
        pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: clean.
        pcmcia_socket pcmcia_socket1: cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff
        pcmcia_socket pcmcia_socket1: cs: IO port probe 0xa00-0xaff: clean.
        pcmcia_socket pcmcia_socket1: cs: IO port probe 0x100-0x3ff: excluding 0x170-0x177 0x1f0-0x1f7 0x2f8-0x2ff 0x370-0x37f 0x3c0-0x3e7 0x3f0-0x3ff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0a0000-0x0affff: excluding 0xa0000-0xaffff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0b0000-0x0bffff: excluding 0xb0000-0xbffff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0cffff: excluding 0xc0000-0xcbfff
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0d0000-0x0dffff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0e0000-0x0effff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: clean.
        pcmcia_socket pcmcia_socket1: cs: memory probe 0x0cc000-0x0effff: excluding 0xe0000-0xeffff
        pcmcia_socket pcmcia_socket1: cs: unable to map card memory!
      
      If filtering out the first 1MB is reverted, everything works as expected.
      Tested-by: NRobert Resch <fli4l@robert.reschpara.de>
      Signed-off-by: NChristoph Schulz <develop@kristov.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v2.6.37+
      cbace46a
  3. 11 7月, 2014 1 次提交
    • B
      x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup() · 20cde694
      Bruno Prémont 提交于
      Commit b4aa0163 ("efifb: Implement vga_default_device() (v2)") added
      efifb vga_default_device() so EFI systems that do not load shadow VBIOS or
      setup VGA get proper value for boot_vga PCI sysfs attribute on the
      corresponding PCI device.
      
      Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such
      as MacBookAir2,1.  Xorg detects the GPU and finds the DRI device but then
      bails out with "no devices detected".
      
      Note: When vga_default_device() is set boot_vga PCI sysfs attribute
      reflects its state.  When unset this attribute is 1 whenever
      IORESOURCE_ROM_SHADOW flag is set.
      
      With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
      while having native drivers for the GPU also makes selecting sysfb/efifb
      optional.
      
      Remove the efifb implementation of vga_default_device() and initialize
      vgaarb's vga_default_device() with the PCI GPU that matches boot
      screen_info in pci_fixup_video().
      
      [bhelgaas: remove unused "dev" in efifb_setup()]
      Fixes: b4aa0163 ("efifb: Implement vga_default_device() (v2)")
      Tested-by: NAnibal Francisco Martinez Cortina <linuxkid.zeuz@gmail.com>
      Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
      CC: stable@vger.kernel.org	# v3.5+
      20cde694
  4. 22 6月, 2014 7 次提交
  5. 05 6月, 2014 1 次提交
    • A
      x86: enable DMA CMA with swiotlb · 9c5a3621
      Akinobu Mita 提交于
      The DMA Contiguous Memory Allocator support on x86 is disabled when
      swiotlb config option is enabled.  So DMA CMA is always disabled on
      x86_64 because swiotlb is always enabled.  This attempts to support for
      DMA CMA with enabling swiotlb config option.
      
      The contiguous memory allocator on x86 is integrated in the function
      dma_generic_alloc_coherent() which is .alloc callback in nommu_dma_ops
      for dma_alloc_coherent().
      
      x86_swiotlb_alloc_coherent() which is .alloc callback in swiotlb_dma_ops
      tries to allocate with dma_generic_alloc_coherent() firstly and then
      swiotlb_alloc_coherent() is called as a fallback.
      
      The main part of supporting DMA CMA with swiotlb is that changing
      x86_swiotlb_free_coherent() which is .free callback in swiotlb_dma_ops
      for dma_free_coherent() so that it can distinguish memory allocated by
      dma_generic_alloc_coherent() from one allocated by
      swiotlb_alloc_coherent() and release it with dma_generic_free_coherent()
      which can handle contiguous memory.  This change requires making
      is_swiotlb_buffer() global function.
      
      This also needs to change .free callback in the dma_map_ops for amd_gart
      and sta2x11, because these dma_ops are also using
      dma_generic_alloc_coherent().
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Don Dutile <ddutile@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9c5a3621
  6. 28 5月, 2014 2 次提交
  7. 24 5月, 2014 1 次提交
  8. 22 5月, 2014 2 次提交
    • S
      x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM · 94d4bb5b
      Suravee Suthikulpanit 提交于
      The BIOS is supposed to provide ACPI _PXM methods for PCI host bridges if
      it cares about platform topology.  But some BIOSes do not, so add Fam15h
      to the list of CPUs for which we fall back to reading node numbers from the
      hardware.
      
      Note that pci_acpi_scan_root() warns about the BIOS bug if we use this
      information because (1) the hardware node numbers are not necessarily
      compatible with other logical node numbers from ACPI, and (2) the lack of
      _PXM forces OS updates that would not otherwise be required.
      
      [bhelgaas: changelog, comments]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051Tested-by: NAravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
      Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Daniel J Blueman <daniel@numascale.com>
      Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
      94d4bb5b
    • M
      x86/PCI: Warn if we have to "guess" host bridge node information · 33673101
      Myron Stowe 提交于
      The vast majority of platforms are not supplying ACPI _PXM (proximity)
      information corresponding to host bridge (PNP0A03/PNP0A08) devices
      resulting in sysfs "numa_node" values of -1 (NUMA_NO_NODE):
      
        # for i in /sys/devices/pci0000\:00/*/numa_node; do cat $i; done | uniq
        -1
      
        # find /sys/ -name "numa_node" | while read fname; do cat $fname; \
          done | uniq
        -1
      
      AMD based platforms provide a fall-back for this situation via amd_bus.c.
      These platforms snoop out the information by directly reading specific
      registers from the Northbridge and caching them via alloc_pci_root_info().
      
      Later during boot processing when host bridges are discovered -
      pci_acpi_scan_root() - the kernel looks for their corresponding ACPI _PXM
      method - drivers/acpi/numa.c::acpi_get_node().  If the BIOS supplied a _PXM
      method then that node (proximity) value is associated.  If the BIOS did not
      supply a _PXM method *and* the platform is AMD-based, the fall-back cached
      values obtained directly from the Northbridge are used; otherwise,
      "NUMA_NO_NODE" is associated.
      
      There are a number of issues with this fall-back mechanism the most notable
      being that amd_bus.c extracts a 3-bit number from a CPU register and uses
      it as the node number.  The node numbers used by Linux are logical and
      there's no reason they need to be identical to settings in the CPU
      registers.  So if we have some node information obtained in the normal way
      (from _PXM, SLIT, SRAT, etc.) and some from amd_bus.c, there's no reason to
      believe they will be compatible.
      
      This patch warns when this situation occurs:
      
        pci_root PNP0A08:00: [Firmware Bug]: no _PXM; falling back to node 0 from hardware (may be inconsistent with ACPI node numbers)
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      33673101
  9. 26 4月, 2014 3 次提交
    • B
      x86/PCI: Mark ATI SBx00 HPET BAR as IORESOURCE_PCI_FIXED · 44c8bdbe
      Bjorn Helgaas 提交于
      Bodo reported that on the Asrock M3A UCC, v3.12.6 hangs during boot unless
      he uses "pci=nocrs".  This regression was caused by 7bc5e3f2 ("x86/PCI:
      use host bridge _CRS info by default on 2008 and newer machines"), which
      appeared in v2.6.34.
      
      The reason is that the HPET address appears in a PCI device BAR, and this
      address is not contained in any of the host bridge windows.  Linux moves
      the PCI BAR into a window, but the original address was published via the
      HPET table and an ACPI device, so changing the BAR is a bad idea.  Here's
      the dmesg info:
      
        ACPI: HPET id: 0x43538301 base: 0xfed00000
        pci_root PNP0A03:00: host bridge window [mem 0xd0000000-0xdfffffff]
        pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
        pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05
        pci 0000:00:14.0: reg 14: [mem 0xfed00000-0xfed003ff]
        hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
        pnp 00:06: Plug and Play ACPI device, IDs PNP0103 (active)
        pnp 00:06: [mem 0xfed00000-0xfed003ff]
      
      When we notice the BAR is not in a host bridge window, we try to move it,
      but that causes a hang shortly thereafter:
      
        pci 0000:00:14.0: no compatible bridge window for [mem 0xfed00000-0xfed003ff]
        pci 0000:00:14.0: BAR 1: assigned [mem 0xf0000000-0xf00003ff]
      
      This patch marks the BAR as IORESOURCE_PCI_FIXED to prevent Linux from
      moving it.  This depends on a previous patch ("x86/PCI: Don't try to move
      IORESOURCE_PCI_FIXED resources") to check for this flag when
      pci_claim_resource() fails.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=68591Reported-and-tested-by: NBodo Eggert <7eggert@gmx.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      44c8bdbe
    • B
      x86/PCI: Don't try to move IORESOURCE_PCI_FIXED resources · 4e4ba944
      Bjorn Helgaas 提交于
      Don't attempt to move resource marked IORESOURCE_PCI_FIXED, even if
      pci_claim_resource() fails.  In some cases, these are legacy resources that
      cannot be moved.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      4e4ba944
    • B
      x86/PCI: Fix Broadcom CNB20LE unintended sign extension · 0b2d7076
      Bjorn Helgaas 提交于
      In the expression "word1 << 16", word1 starts as u16, but is promoted to
      a signed int, then sign-extended to resource_size_t, which is probably
      not what was intended.  Cast to resource_size_t to avoid the sign
      extension.
      
      Found by Coverity (CID 138749, 138750).
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      0b2d7076
  10. 20 3月, 2014 1 次提交
    • S
      x86, pci, amd-bus: Fix CPU hotplug callback registration · 9f668f66
      Srivatsa S. Bhat 提交于
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the amd-bus code in x86 by using this latter form of callback
      registration.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9f668f66
  11. 18 3月, 2014 1 次提交
    • R
      xen: add support for MSI message groups · 4892c9b4
      Roger Pau Monne 提交于
      Add support for MSI message groups for Xen Dom0 using the
      MAP_PIRQ_TYPE_MULTI_MSI pirq map type.
      
      In order to keep track of which pirq is the first one in the group all
      pirqs in the MSI group except for the first one have the newly
      introduced PIRQ_MSI_GROUP flag set. This prevents calling
      PHYSDEVOP_unmap_pirq on them, since the unmap must be done with the
      first pirq in the group.
      Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      4892c9b4
  12. 28 2月, 2014 2 次提交
  13. 15 2月, 2014 1 次提交
  14. 13 2月, 2014 3 次提交
  15. 04 2月, 2014 11 次提交
  16. 16 1月, 2014 1 次提交
  17. 07 1月, 2014 1 次提交