An error occurred fetching the project authors.
- 19 Mar, 2018 1 commit
-
-
Bjorn Helgaas authored
Remove pointless comments that tell us the file name, remove blank line comments, follow multi-line comment conventions. No functional change intended. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 26 Jan, 2018 1 commit
-
-
Bjorn Helgaas authored
b2441318 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") added SPDX GPL-2.0 to several PCI files that previously contained no license information. Add SPDX GPL-2.0 to all other PCI files that did not contain any license information and hence were under the default GPL version 2 license of the kernel. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 Jan, 2018 1 commit
-
-
Frederick Lawler authored
Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended. Signed-off-by:
Frederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 05 Oct, 2017 1 commit
-
-
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:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 01 Aug, 2017 1 commit
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 27 Jun, 2017 5 commits
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 14 Jun, 2017 1 commit
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 07 Jun, 2017 1 commit
-
-
Andy Shevchenko authored
acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 bytes. Instead we convert them to use guid_t type. At the same time we convert current users. acpi_str_to_uuid() becomes useless after the conversion and it's safe to get rid of it. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Borislav Petkov <bp@suse.de> Acked-by:
Dan Williams <dan.j.williams@intel.com> Cc: Amir Goldstein <amir73il@gmail.com> Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Joerg Roedel <jroedel@suse.de> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
- 06 Dec, 2016 1 commit
-
-
Dongdong Liu authored
The acpi_get_rc_resources() is used to get the RC register address that can not be described in MCFG. It takes the _HID & segment to look for and outputs the RC address resource. Use PNP0C02 devices to describe such RC address resource. Use _UID to match segment to tell which root bus the PNP0C02 resource belongs to. [bhelgaas: add dev argument, wrap in #ifdef CONFIG_PCI_QUIRKS] Signed-off-by:
Dongdong Liu <liudongdong3@huawei.com> Signed-off-by:
Tomasz Nowicki <tn@semihalf.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 18 Nov, 2016 1 commit
-
-
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:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 Sep, 2016 1 commit
-
-
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:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 21 Dec, 2015 1 commit
-
-
Suravee Suthikulpanit authored
This patch introduces pci_msi_register_fwnode_provider() for irqchip to register a callback, to provide a way to determine appropriate MSI domain for a pci device. It also introduces pci_host_bridge_acpi_msi_domain(), which returns the MSI domain of the specified PCI host bridge with DOMAIN_BUS_PCI_MSI bus token. Then, it is assigned to pci device. Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by:
Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
- 09 Dec, 2015 1 commit
-
-
Julia Lawall authored
The pci_platform_pm_ops structure is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 Jul, 2015 1 commit
-
-
Srinidhi Kasagar authored
The function takes ACPI handle, not the device itself. Fix the comment Signed-off-by:
Srinidhi Kasagar <srinidhi.kasagar@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 15 May, 2015 1 commit
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 Apr, 2015 3 commits
-
-
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:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
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:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
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:
Michael D Labriola <mlabriol@gdeb.com> Tested-by:
Michael D Labriola <mlabriol@gdeb.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.18+
-
- 23 Jan, 2015 1 commit
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 11 Nov, 2014 1 commit
-
-
Markus Elfring authored
The functions pci_dev_put(), pci_pme_wakeup_bus(), and put_device() return immediately if their argument is NULL. Thus the test before the call is not needed. Remove these unnecessary tests. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 13 Sep, 2014 3 commits
-
-
Bjorn Helgaas authored
Move code around to put all the ACPI power management stuff together and all the pieces related to ACPI methods (_CBA, _HPP, _HPX) together. No functional change. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Whitespace fixes only; no functional change. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Bjorn Helgaas authored
Move pci_get_hp_params() and related functions from drivers/pci/hotplug/acpi_pcihp.c to drivers/pci/pci-acpi.c. Previously, pci_get_hp_params() was used only by hotplug drivers. But future changes will move this into the normal device enumeration process, so it will be used even when CONFIG_HOTPLUG_PCI is not set. No functional change. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 23 Jul, 2014 1 commit
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 22 Jul, 2014 1 commit
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 27 May, 2014 1 commit
-
-
Yijing Wang authored
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cda PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c PCI: Add new pci_is_bridge() interface Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 29 Dec, 2013 1 commit
-
-
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:
Agustin Barto <abarto@gmail.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 09 Dec, 2013 1 commit
-
-
Yijing Wang authored
Use dev_is_pci() instead of checking bus type directly. Signed-off-by:
Yijing Wang <wangyijing@huawei.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 07 Dec, 2013 3 commits
-
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> # for USB/ACPI
-
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Aaron Lu <aaron.lu@intel.com>
-
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:
Lv 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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 Nov, 2013 2 commits
-
-
Rafael J. Wysocki authored
Since DEVICE_ACPI_HANDLE() is now literally identical to ACPI_HANDLE(), replace it with the latter everywhere and drop its definition from include/acpi.h. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bjorn Helgaas authored
Fix whitespace, capitalization, and spelling errors. No functional change. I know "busses" is not an error, but "buses" was more common, so I used it consistently. Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus()) Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 23 Sep, 2013 1 commit
-
-
Zhang Rui authored
acpi_has_method() is a new ACPI API introduced to check the existence of an ACPI control method. It can be used to replace acpi_get_handle() in the case that 1. the calling function doesn't need the ACPI handle of the control method. and 2. the calling function doesn't care the reason why the method is unavailable. Convert acpi_get_handle() to acpi_has_method() in drivers/pci/pci-acpi.c in this patch. Signed-off-by:
Zhang Rui <rui.zhang@intel.com> CC: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 19 Sep, 2013 1 commit
-
-
Rafael J. Wysocki authored
Commit 448bd857 (PCI/PM: add PCIe runtime D3cold support) added a piece of code to pci_acpi_wake_dev() causing that function to behave in a special way for devices in D3cold (so that their configuration registers are not accessed before those devices are resumed). However, it didn't take the clearing of the pme_poll flag into account. That has to be done for all devices, even if they are in D3cold, or pci_pme_list_scan() will not know that wakeup has been signaled for the device and will poll its PME Status bit unnecessarily. Fix the problem by moving the clearing of the pme_poll flag in pci_acpi_wake_dev() before the code introduced by commit 448bd857. Reported-and-tested-by:
David E. Box <david.e.box@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: 3.6+ <stable@vger.kernel.org> # 3.6+
-
- 07 Aug, 2013 1 commit
-
-
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:
Peter Wu <lekensteyn@gmail.com> Tested-by:
Vladimir Lalov <mail@vlalov.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
-