1. 05 Dec, 2011 7 commits
    • Rafael J. Wysocki's avatar
      PCI/ACPI/PM: Avoid resuming devices that don't signal PME · a424948d
      Rafael J. Wysocki authored
      Modify pci_acpi_wake_dev() to avoid resuming PME-capable devices
      whose PME Status bits are not set, which may happen currently if
      several devices are associated with the same wakeup GPE and all
      of them are notified whenever at least one of them signals PME.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      a424948d
    • Rafael J. Wysocki's avatar
      PCI/ACPI: Make acpiphp ignore root bridges using SHPC native hotplug · d90116ea
      Rafael J. Wysocki authored
      If the kernel has requested control of the SHPC native hotplug
      feature for a given root bridge, the acpiphp driver should not try
      to handle that root bridge and it should leave it to shpchp.
      Failing to do so causes problems to happen if shpchp is loaded
      and unloaded before loading acpiphp (ACPI-based hotplug won't work
      in that case anyway).
      
      To address this issue make find_root_bridges() ignore PCI root
      bridges with SHPC native hotplug enabled and make add_bridge()
      return error code if SHPC native hotplug is enabled for the given
      root bridge.  This causes acpiphp to refuse to load if SHPC native
      hotplug is enabled for all root bridges and to refuse binding to
      the root bridges with SHPC native hotplug enabled.
      Reviewed-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      d90116ea
    • Kenji Kaneshige's avatar
      PCI: pciehp: Handle push button event asynchronously · 486b10b9
      Kenji Kaneshige authored
      Use non-ordered workqueue for attention button events.
      
      Attention button events on each slot can be handled asynchronously. So
      we should use non-ordered workqueue. This patch also removes ordered
      workqueue in pciehp as a result.
      Signed-off-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      486b10b9
    • Kenji Kaneshige's avatar
      PCI: pciehp: Fix wrong workqueue cleanup · 027e8d52
      Kenji Kaneshige authored
      Fix improper workqueue cleanup.
      
      In the current pciehp, pcied_cleanup() calls destroy_workqueue()
      before calling pcie_port_service_unregister(). This causes kernel oops
      because flush_workqueue() is called in the pcie_port_service_unregister()
      code path after the workqueue was destroyed. So pcied_cleanup() must call
      pcie_port_service_unregister() first before calling destroy_workqueue().
      Signed-off-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      027e8d52
    • Matthew Garrett's avatar
      PCI: Rework ASPM disable code · 3c076351
      Matthew Garrett authored
      Right now we forcibly clear ASPM state on all devices if the BIOS indicates
      that the feature isn't supported. Based on the Microsoft presentation
      "PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
      that this may be an error. The implication is that unless the platform
      grants full control via _OSC, Windows will not touch any PCIe features -
      including ASPM. In that case clearing ASPM state would be an error unless
      the platform has granted us that control.
      
      This patch reworks the ASPM disabling code such that the actual clearing
      of state is triggered by a successful handoff of PCIe control to the OS.
      The general ASPM code undergoes some changes in order to ensure that the
      ability to clear the bits isn't overridden by ASPM having already been
      disabled. Further, this theoretically now allows for situations where
      only a subset of PCIe roots hand over control, leaving the others in the
      BIOS state.
      
      It's difficult to know for sure that this is the right thing to do -
      there's zero public documentation on the interaction between all of these
      components. But enough vendors enable ASPM on platforms and then set this
      bit that it seems likely that they're expecting the OS to leave them alone.
      
      Measured to save around 5W on an idle Thinkpad X220.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      3c076351
    • Alex Williamson's avatar
      PCI: Fix PRI and PASID consistency · 69166fbf
      Alex Williamson authored
      These are extended capabilities, rename and move to proper
      group for consistency.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      69166fbf
    • Neil Horman's avatar
      PCI/sysfs: add per pci device msi[x] irq listing (v5) · b50cac55
      Neil Horman authored
      This patch adds a per-pci-device subdirectory in sysfs called:
      /sys/bus/pci/devices/<device>/msi_irqs
      
      This sub-directory exports the set of msi vectors allocated by a given
      pci device, by creating a numbered sub-directory for each vector beneath
      msi_irqs.  For each vector various attributes can be exported.
      Currently the only attribute is called mode, which tracks the
      operational mode of that vector (msi vs. msix)
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b50cac55
  2. 04 Dec, 2011 1 commit
    • Linus Torvalds's avatar
      x86: Fix boot failures on older AMD CPU's · 8e8da023
      Linus Torvalds authored
      People with old AMD chips are getting hung boots, because commit
      bcb80e53 ("x86, microcode, AMD: Add microcode revision to
      /proc/cpuinfo") moved the microcode detection too early into
      "early_init_amd()".
      
      At that point we are *so* early in the booth that the exception tables
      haven't even been set up yet, so the whole
      
      	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
      
      doesn't actually work: if the rdmsr does a GP fault (due to non-existant
      MSR register on older CPU's), we can't fix it up yet, and the boot fails.
      
      Fix it by simply moving the code to a slightly later point in the boot
      (init_amd() instead of early_init_amd()), since the kernel itself
      doesn't even really care about the microcode patchlevel at this point
      (or really ever: it's made available to user space in /proc/cpuinfo, and
      updated if you do a microcode load).
      Reported-tested-and-bisected-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Tested-by: default avatarBob Tracy <rct@gherkin.frus.com>
      Acked-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8e8da023
  3. 03 Dec, 2011 1 commit
    • Konrad Rzeszutek Wilk's avatar
      xen/pm_idle: Make pm_idle be default_idle under Xen. · e5fd47bf
      Konrad Rzeszutek Wilk authored
      The idea behind commit d91ee586 ("cpuidle: replace xen access to x86
      pm_idle and default_idle") was to have one call - disable_cpuidle()
      which would make pm_idle not be molested by other code.  It disallows
      cpuidle_idle_call to be set to pm_idle (which is excellent).
      
      But in the select_idle_routine() and idle_setup(), the pm_idle can still
      be set to either: amd_e400_idle, mwait_idle or default_idle.  This
      depends on some CPU flags (MWAIT) and in AMD case on the type of CPU.
      
      In case of mwait_idle we can hit some instances where the hypervisor
      (Amazon EC2 specifically) sets the MWAIT and we get:
      
        Brought up 2 CPUs
        invalid opcode: 0000 [#1] SMP
      
        Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
        RIP: e030:[<ffffffff81015d1d>]  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
        ...
        Call Trace:
         [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
         [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
        RIP  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
         RSP <ffff8801d28ddf10>
      
      In the case of amd_e400_idle we don't get so spectacular crashes, but we
      do end up making an MSR which is trapped in the hypervisor, and then
      follow it up with a yield hypercall.  Meaning we end up going to
      hypervisor twice instead of just once.
      
      The previous behavior before v3.0 was that pm_idle was set to
      default_idle regardless of select_idle_routine/idle_setup.
      
      We want to do that, but only for one specific case: Xen.  This patch
      does that.
      
      Fixes RH BZ #739499 and Ubuntu #881076
      Reported-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e5fd47bf
  4. 02 Dec, 2011 14 commits
  5. 01 Dec, 2011 17 commits