An error occurred fetching the project authors.
  1. 19 Mar, 2018 1 commit
  2. 26 Jan, 2018 1 commit
  3. 18 Jan, 2018 1 commit
  4. 05 Oct, 2017 1 commit
    • Vitaly Kuznetsov's avatar
      ACPI / PCI: Bail early in acpi_pci_add_bus() if there is no ACPI handle · a0040c01
      Vitaly Kuznetsov authored
      Hyper-V instances support PCI pass-through which is implemented through PV
      pci-hyperv driver. When a device is passed through, a new root PCI bus is
      created in the guest. The bus sits on top of VMBus and has no associated
      information in ACPI. acpi_pci_add_bus() in this case proceeds all the way
      to acpi_evaluate_dsm(), which reports
      
        ACPI: \: failed to evaluate _DSM (0x1001)
      
      While acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() are protected
      against ACPI_HANDLE() being NULL and do nothing, acpi_evaluate_dsm() is not
      and gives us the error. It seems the correct fix is to not do anything in
      acpi_pci_add_bus() in such cases.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      a0040c01
  5. 01 Aug, 2017 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup() · 1ba51a7c
      Rafael J. Wysocki authored
      The acpi_pci_propagate_wakeup() routine is there to handle cases in
      which PCI bridges (or PCIe ports) are expected to signal wakeup
      for devices below them, but currently it doesn't do that correctly.
      
      The problem is that acpi_pci_propagate_wakeup() uses
      acpi_pm_set_device_wakeup() for bridges and if that routine is
      called for multiple times to disable wakeup for the same device,
      it will disable it on the first invocation and the next calls
      will have no effect (it works analogously when called to enable
      wakeup, but that is not a problem).
      
      Now, say acpi_pci_propagate_wakeup() has been called for two
      different devices under the same bridge and it has called
      acpi_pm_set_device_wakeup() for that bridge each time.  The
      bridge is now enabled to generate wakeup signals.  Next,
      suppose that one of the devices below it resumes and
      acpi_pci_propagate_wakeup() is called to disable wakeup for that
      device.  It will then call acpi_pm_set_device_wakeup() for the bridge
      and that will effectively disable remote wakeup for all devices under
      it even though some of them may still be suspended and remote wakeup
      may be expected to work for them.
      
      To address this (arguably theoretical) issue, allow
      wakeup.enable_count under struct acpi_device to grow beyond 1 in
      certain situations.  In particular, allow that to happen in
      acpi_pci_propagate_wakeup() when wakeup is enabled or disabled
      for PCI bridges, so that wakeup is actually disabled for the
      bridge when all devices under it resume and not when just one
      of them does that.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      1ba51a7c
  6. 27 Jun, 2017 5 commits
    • Rafael J. Wysocki's avatar
      PM / core: Drop run_wake flag from struct dev_pm_info · de3ef1eb
      Rafael J. Wysocki authored
      The run_wake flag in struct dev_pm_info is used to indicate whether
      or not the device is capable of generating remote wakeup signals at
      run time (or in the system working state), but the distinction
      between runtime remote wakeup and system wakeup signaling has always
      been rather artificial.  The only practical reason for it to exist
      at the core level was that ACPI and PCI treated those two cases
      differently, but that's not the case any more after recent changes.
      
      For this reason, get rid of the run_wake flag and, when applicable,
      use device_set_wakeup_capable() and device_can_wakeup() instead of
      device_set_run_wake() and device_run_wake(), respectively.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      de3ef1eb
    • Rafael J. Wysocki's avatar
      PCI / PM: Simplify device wakeup settings code · 0847684c
      Rafael J. Wysocki authored
      After previous changes it is not necessary to distinguish between
      device wakeup for run time and device wakeup from system sleep states
      any more, so rework the PCI device wakeup settings code accordingly.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0847684c
    • Rafael J. Wysocki's avatar
      PCI / PM: Drop pme_interrupt flag from struct pci_dev · 8370c2dc
      Rafael J. Wysocki authored
      The pme_interrupt flag in struct pci_dev is set when PMEs generated
      by the device are going to be signaled via root port PME interrupts.
      
      Ironically enough, that information is only used by the code setting
      up device wakeup through ACPI which returns as soon as it sees the
      pme_interrupt flag set while setting up "remote runtime wakeup".
      That is questionable, however, because in theory there may be PCIe
      devices using out-of-band PME signaling under root ports handled
      by the native PME code or devices requiring wakeup power setup to be
      carried out by AML.  For such devices, ACPI wakeup should be invoked
      regardless of whether or not native PME signaling is used in general.
      
      For this reason, drop the pme_interrupt flag and rework the code
      using it which then allows the ACPI-based device wakeup handling
      in PCI to be consolidated to use one code path for both "runtime
      remote wakeup" and system wakeup (from sleep states).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      8370c2dc
    • Rafael J. Wysocki's avatar
      ACPI / PM: Consolidate device wakeup settings code · 4d183d04
      Rafael J. Wysocki authored
      Currently, there are two separate ways of handling device wakeup
      settings in the ACPI core, depending on whether this is runtime
      wakeup or system wakeup (from sleep states).  However, after the
      previous commit eliminating the run_wake ACPI device wakeup flag,
      there is no difference between the two any more at the ACPI level,
      so they can be combined.
      
      For this reason, introduce acpi_pm_set_device_wakeup() to replace both
      acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake() and make it
      check the ACPI device object's wakeup.valid flag to determine whether
      or not the device can be set up to generate wakeup signals.
      
      Also notice that zpodd_enable/disable_run_wake() only call
      device_set_run_wake() because acpi_pm_device_run_wake() called
      device_run_wake(), which is not done by acpi_pm_set_device_wakeup(),
      so drop the now redundant device_set_run_wake() calls from there.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      4d183d04
    • Rafael J. Wysocki's avatar
      ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags · a1a66393
      Rafael J. Wysocki authored
      The run_wake flag in struct acpi_device_wakeup_flags stores the
      information on whether or not the device can generate wakeup
      signals at run time, but in ACPI that really is equivalent to
      being able to generate wakeup signals at all.
      
      In fact, run_wake will always be set after successful executeion of
      acpi_setup_gpe_for_wake(), but if that fails, the device will not be
      able to use a wakeup GPE at all, so it won't be able to wake up the
      systems from sleep states too.  Hence, run_wake actually means that
      the device is capable of triggering wakeup and so it is equivalent
      to the valid flag.
      
      For this reason, drop run_wake from struct acpi_device_wakeup_flags
      and make sure that the valid flag is only set if
      acpi_setup_gpe_for_wake() has been successful.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      a1a66393
  7. 14 Jun, 2017 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Run wakeup notify handlers synchronously · 64fd1c70
      Rafael J. Wysocki authored
      The work functions provided by the users of acpi_add_pm_notifier()
      should be run synchronously before re-enabling the wakeup GPE in
      case they are used to clear the status and/or disable the wakeup
      signaling at the source.  Otherwise, which is the case currently in
      the PCI bus type code, the same wakeup event may be signaled for
      multiple times while the execution of the work function in response
      to it has already been queued up.
      
      Fortunately, acpi_add_pm_notifier() is only used by PCI and by
      ACPI device PM code internally, so the change is relatively
      straightforward to make.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      64fd1c70
  8. 07 Jun, 2017 1 commit
  9. 06 Dec, 2016 1 commit
  10. 18 Nov, 2016 1 commit
    • Lukas Wunner's avatar
      ACPI / hotplug / PCI: Make device_is_managed_by_native_pciehp() public · 437eb7bf
      Lukas Wunner authored
      We're about to add runtime PM of hotplug ports, but we need to restrict it
      to ports that are handled natively by the OS:  If they're handled by the
      firmware (which is the case for Thunderbolt on non-Macs), things would
      break if the OS put the ports into D3hot behind the firmware's back.
      
      To determine if a hotplug port is handled natively, one has to walk up from
      the port to the root bridge and check the cached _OSC Control Field for the
      value of the "PCI Express Native Hot Plug control" bit.  There's already a
      function to do that, device_is_managed_by_native_pciehp(), but it's private
      to drivers/pci/hotplug/acpiphp_glue.c and only compiled in if
      CONFIG_HOTPLUG_PCI_ACPI is enabled.
      
      Make it public and move it to drivers/pci/pci-acpi.c, so that it is
      available in the more general CONFIG_ACPI case.
      
      The function contains a check if the device in question is a hotplug port
      and returns false if it's not.  The caller we're going to add doesn't need
      this as it only calls the function if it actually *is* a hotplug port.
      Move the check out of the function into the single existing caller.
      
      Rename it to pciehp_is_native() and add some kerneldoc and polish.
      
      No functional change intended.
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      437eb7bf
  11. 28 Sep, 2016 1 commit
    • Lukas Wunner's avatar
      PCI: Query platform firmware for device power state · cc7cc02b
      Lukas Wunner authored
      Usually the most accurate way to determine a PCI device's power state is to
      read its PM Control & Status Register.  There are two cases however when
      this is not an option:  If the device doesn't have the PM capability at
      all, or if it is in D3cold (in which case its config space is
      inaccessible).
      
      In both cases, we can alternatively query the platform firmware for its
      opinion on the device's power state.  To facilitate this, augment struct
      pci_platform_pm_ops with a ->get_power callback and implement it for
      acpi_pci_platform_pm (the only pci_platform_pm_ops existing so far).
      
      It is used by a forthcoming commit to let pci_update_current_state()
      recognize D3cold.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cc7cc02b
  12. 21 Dec, 2015 1 commit
  13. 09 Dec, 2015 1 commit
  14. 15 Jul, 2015 1 commit
  15. 15 May, 2015 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Rework device power management to follow ACPI 6 · 20dacb71
      Rafael J. Wysocki authored
      The ACPI 6 specification has made some changes in the device power
      management area.  In particular:
      
       * The D3hot power state is now supposed to be always available
         (instead of D3cold) and D3cold is only regarded as valid if the
         _PR3 object is present for the given device.
      
       * The required ordering of transitions into power states deeper than
         D0 is now such that for a transition into state Dx the _PSx method
         is supposed to be executed first, if present, and the states of
         the power resources the device depends on are supposed to be
         changed after that.
      
       * It is now explicitly forbidden to transition devices from
         lower-power (deeper) into higher-power (shallower) power states
         other than D0.
      
      Those changes have been made so the specification reflects the
      Windows' device power management code that the vast majority of
      systems using ACPI is validated against.
      
      To avoid artificial differences in ACPI device power management
      between Windows and Linux, modify the ACPI device power management
      code to follow the new specification.  Add comments explaining the
      code flow in some unclear places.
      
      This only may affect some real corner cases in which the OS behavior
      expected by the firmware is different from the Windows one, but that's
      quite unlikely.  The transition ordering change affects transitions
      to D1 and D2 which are rarely used (if at all) and into D3hot and
      D3cold for devices actually having _PR3, but those are likely to
      be validated against Windows anyway.  The other changes may affect
      code calling acpi_device_get_power() or acpi_device_update_power()
      where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD
      (that's why the ACPI fan driver needs to be updated too) and since
      transitions into ACPI_STATE_D3_HOT may remove power now, it is better
      to avoid this one in acpi_pm_device_sleep_state() if the "no power
      off" PM QoS flag is set.
      
      The only existing user of acpi_device_can_poweroff() really cares
      about the case when _PR3 is present, so the change in that function
      should not cause any problems to happen too.
      
      A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT
      now and the compatibility with older systems should be covered
      automatically.
      
      In any case, if any real problems result from this, it still will
      be better to follow the Windows' behavior (which now is reflected
      by the specification too) in general and handle the cases when it
      doesn't work via quirks.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      20dacb71
  16. 08 Apr, 2015 3 commits
    • Aaron Lu's avatar
      PCI/ACPI: Optimize device state transition delays · e33caa82
      Aaron Lu authored
      The PCI "ACPI additions for FW latency optimizations" ECN (link below)
      defines two functions in the PCI _DSM:
      
        Function 8, "Reset Delay," applies to the entire hierarchy below a PCI
        host bridge.  If it returns one, the OS may assume that all devices in
        the hierarchy have already completed power-on reset delays.
      
        Function 9, "Device Readiness Durations," applies only to the object
        where it is located.  It returns delay durations required after various
        events if the device requires less time than the spec requires.  Delays
        from this function take precedence over the Reset Delay function.
      
      Add support for Reset Delay and part of Device Readiness Durations.
      
      [bhelgaas: changelog, comments]
      Link: https://www.pcisig.com/specifications/conventional/pci_firmware/ECN_fw_latency_optimization_final.pdfSigned-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      e33caa82
    • Aaron Lu's avatar
      PCI: Make a shareable UUID for PCI firmware ACPI _DSM · 18e94a33
      Aaron Lu authored
      The PCI Firmware Specification, r3.0, sec 4.6.4.1.3, defines a single UUID
      for an ACPI _DSM method to provide device-specific control functions.  This
      _DSM method support several functions, including PCI Express Slot
      Information, PCI Express Slot Number, PCI Bus Capabilities, etc.
      
      Move the UUID definition from pci/pci-label.c, where it could be used only
      for one function, to pci/pci-acpi.c where it can be shared for all these
      functions.
      
      [bhelgaas: changelog]
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      18e94a33
    • Bjorn Helgaas's avatar
      PCI: Don't look for ACPI hotplug parameters if ACPI is disabled · 8647ca9a
      Bjorn Helgaas authored
      Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
      results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
      hypervisor and 32-bit domU):
      
        BUG: unable to handle kernel paging request at 0030303e
        IP: [<c06ed0e6>] acpi_ns_validate_handle+0x12/0x1a
        Call Trace:
         [<c06eda4d>] ? acpi_evaluate_object+0x31/0x1fc
         [<c06b78e1>] ? pci_get_hp_params+0x111/0x4e0
         [<c0407bc7>] ? xen_force_evtchn_callback+0x17/0x30
         [<c04085fb>] ? xen_restore_fl_direct_reloc+0x4/0x4
         [<c0699d34>] ? pci_device_add+0x24/0x450
      
      Don't look for ACPI configuration information if ACPI has been disabled.
      
      I don't think this is the best fix, because we can boot plain Linux (no
      Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
      There should be a better fix that would make Xen domU work the same way.
      The domU kernel has ACPI support but it has no AML.  There should be a way
      to initialize the ACPI data structures so things fail gracefully rather
      than oopsing.  This is an interim fix to address the regression.
      
      Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301Reported-by: default avatarMichael D Labriola <mlabriol@gdeb.com>
      Tested-by: default avatarMichael D Labriola <mlabriol@gdeb.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.18+
      8647ca9a
  17. 23 Jan, 2015 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Avoid resuming PCI devices during system suspend · bac2a909
      Rafael J. Wysocki authored
      Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM
      domain during system suspend) modified the ACPI PM domain's system
      suspend callbacks to allow devices attached to it to be left in the
      runtime-suspended state during system suspend so as to optimize
      the suspend process.
      
      This was based on the general mechanism introduced by commit
      aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended
      devices unnecessarily).
      
      Extend that approach to PCI devices by modifying the PCI bus type's
      ->prepare callback to return 1 for devices that are runtime-suspended
      when it is being executed and that are in a suitable power state and
      need not be resumed going forward.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      bac2a909
  18. 11 Nov, 2014 1 commit
  19. 13 Sep, 2014 3 commits
  20. 23 Jul, 2014 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PCI: Use ACPI_COMPANION() instead of ACPI_HANDLE() · 85dbb3d0
      Rafael J. Wysocki authored
      The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
      return the handle of the device's ACPI companion, so it is much
      more straightforward and efficient to use ACPI_COMPANION()
      directly to obtain the device's ACPI companion object instead of
      using ACPI_HANDLE() and acpi_bus_get_device() on the returned
      handle for the same thing.
      
      Use ACPI_COMPANION() instead of ACPI_HANDLE() in the PCI ACPI support
      code.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      85dbb3d0
  21. 22 Jul, 2014 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Revork the handling of ACPI device wakeup notifications · c072530f
      Rafael J. Wysocki authored
      Since ACPI wakeup GPEs are going to be enabled during system suspend
      as well as for runtime wakeup by a subsequent patch and the same
      notify handlers will be used in both cases, rework the ACPI device
      wakeup notification framework so that the part specific to physical
      devices is always run asynchronously from the PM workqueue.  This
      prevents runtime resume callbacks for those devices from being
      run during system suspend and resume which may not be appropriate,
      among other things.
      
      Also make ACPI device wakeup notification handling a bit more robust
      agaist subsequent removal of ACPI device objects, whould that ever
      happen, and create a wakeup source object for each ACPI device
      configured for wakeup so that wakeup notifications for those
      devices can wake up the system from the "freeze" sleep state.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c072530f
  22. 27 May, 2014 1 commit
  23. 29 Dec, 2013 1 commit
    • Rafael J. Wysocki's avatar
      PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI · f084280c
      Rafael J. Wysocki authored
      It turns out that some BIOSes don't report wakeup GPEs through
      _PRW, but use them for signaling wakeup anyway, which causes GPE
      storms to occur on some systems after resume from system suspend.
      This issue has been uncovered by commit d2e5f0c1 (ACPI / PCI:
      Rework the setup and cleanup of device wakeup) during the 3.9
      development cycle.
      
      Work around the problem by installing wakeup notify handlers for all
      PCI devices with ACPI support (i.e. having ACPI companions) regardless
      of whether or not the BIOS reports ACPI wakeup support for them.  The
      presence of the wakeup notify handlers alone is not harmful in any
      way if there are no events for them to handle (they are simply never
      executed then), but on some systems they are needed to take care of
      spurious events.
      
      Fixes: d2e5f0c1 (ACPI / PCI: Rework the setup and cleanup of device wakeup)
      References: https://bugzilla.kernel.org/show_bug.cgi?id=63021Reported-and-tested-by: default avatarAgustin Barto <abarto@gmail.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f084280c
  24. 09 Dec, 2013 1 commit
  25. 07 Dec, 2013 3 commits
    • Rafael J. Wysocki's avatar
      ACPI / bind: Rework struct acpi_bus_type · e3f02c52
      Rafael J. Wysocki authored
      Replace the .find_device function pointer in struct acpi_bus_type
      with a new one, .find_companion, that is supposed to point to a
      function returning struct acpi_device pointer (instead of an int)
      and takes one argument (instead of two).  This way the role of
      this callback is more clear and the implementation of it can
      be more straightforward.
      
      Update all of the users of struct acpi_bus_type (PCI, PNP/ACPI and
      USB) to reflect the structure change.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: Lan Tianyu <tianyu.lan@intel.com> # for USB/ACPI
      e3f02c52
    • Rafael J. Wysocki's avatar
      PCI / ACPI: Use acpi_find_child_device() for child devices lookup · 5ce79d20
      Rafael J. Wysocki authored
      It is much more efficient to use acpi_find_child_device()
      for child devices lookup in acpi_pci_find_device() and pass
      ACPI_COMPANION(dev->parent) to it directly instead of obtaining
      ACPI_HANDLE() of ACPI_COMPANION(dev->parent) and passing it to
      acpi_find_child() which has to run acpi_bus_get_device() to
      obtain ACPI_COMPANION(dev->parent) from that again.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarAaron Lu <aaron.lu@intel.com>
      5ce79d20
    • Lv Zheng's avatar
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      Lv Zheng authored
      Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
      <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
      inclusions and remove some inclusions of those files that aren't
      necessary.
      
      First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
      should not be included directly from any files that are built for
      CONFIG_ACPI unset, because that generally leads to build warnings about
      undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
      <linux/acpi.h> includes those files and for CONFIG_ACPI unset it
      provides stub ACPI symbols to be used in that case.
      
      Second, there are ordering dependencies between those files that always
      have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
      prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
      latter depends on are always there.  And <acpi/acpi.h> which provides
      basic ACPICA type declarations should always be included prior to any other
      ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
      <linux/acpi.h> as appropriate.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8b48463f
  26. 14 Nov, 2013 2 commits
  27. 23 Sep, 2013 1 commit
  28. 19 Sep, 2013 1 commit
  29. 07 Aug, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI: Try harder to resolve _ADR collisions for bridges · 60f75b8e
      Rafael J. Wysocki authored
      In theory, under a given ACPI namespace node there should be only
      one child device object with _ADR whose value matches a given bus
      address exactly.  In practice, however, there are systems in which
      multiple child device objects under a given parent have _ADR matching
      exactly the same address.  In those cases we use _STA to determine
      which of the multiple matching devices is enabled, since some systems
      are known to indicate which ACPI device object to associate with the
      given physical (usually PCI) device this way.
      
      Unfortunately, as it turns out, there are systems in which many
      device objects under the same parent have _ADR matching exactly the
      same bus address and none of them has _STA, in which case they all
      should be regarded as enabled according to the spec.  Still, if
      those device objects are supposed to represent bridges (e.g. this
      is the case for device objects corresponding to PCIe ports), we can
      try harder and skip the ones that have no child device objects in the
      ACPI namespace.  With luck, we can avoid using device objects that we
      are not expected to use this way.
      
      Although this only works for bridges whose children also have ACPI
      namespace representation, it is sufficient to address graphics
      adapter detection issues on some systems, so rework the code finding
      a matching device ACPI handle for a given bus address to implement
      this idea.
      
      Introduce a new function, acpi_find_child(), taking three arguments:
      the ACPI handle of the device's parent, a bus address suitable for
      the device's bus type and a bool indicating if the device is a
      bridge and make it work as outlined above.  Reimplement the function
      currently used for this purpose, acpi_get_child(), as a call to
      acpi_find_child() with the last argument set to 'false' and make
      the PCI subsystem use acpi_find_child() with the bridge information
      passed as the last argument to it.  [Lan Tianyu notices that it is
      not sufficient to use pci_is_bridge() for that, because the device's
      subordinate pointer hasn't been set yet at this point, so use
      hdr_type instead.]
      
      This change fixes a regression introduced inadvertently by commit
      33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which
      overlooked the fact that for acpi_walk_namespace() "post-order" means
      "after all children have been visited" rather than "on the way back",
      so for device objects without children and for namespace walks of
      depth 1, as in the acpi_get_child() case, the "post-order" callbacks
      ordering is actually the same as the ordering of "pre-order" ones.
      Since that commit changed the namespace walk in acpi_get_child() to
      terminate after finding the first matching object instead of going
      through all of them and returning the last one, it effectively
      changed the result returned by that function in some rare cases and
      that led to problems (the switch from a "pre-order" to a "post-order"
      callback was supposed to prevent that from happening, but it was
      ineffective).
      
      As it turns out, the systems where the change made by commit
      33f767d7 actually matters are those where there are multiple ACPI
      device objects representing the same PCIe port (which effectively
      is a bridge).  Moreover, only one of them, and the one we are
      expected to use, has child device objects in the ACPI namespace,
      so the regression can be addressed as described above.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by: default avatarPeter Wu <lekensteyn@gmail.com>
      Tested-by: default avatarVladimir Lalov <mail@vlalov.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
      60f75b8e