When a CPU reads the Vendor and Device ID of a non-existent device, the
controller should fabricate return data of 0xFFFFFFFF. Configuration
Request Retry Status (CRS) is not applicable in this case because the
device doesn't exist at all.
The X-Gene v1 PCIe controller has a bug in the CRS logic such that when CRS
is enabled, it fabricates return data of 0xFFFF0001 for this case, which
means "the device exists but is not ready." That causes the PCI core to
retry the read until it times out after 60 seconds.
Disable CRS capability advertisement by clearing the CRS Software
Visibility bit in the Root Capabilities Register.
[bhelgaas: changelog and comment]
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Signed-off-by: Duc Dang <dhdang@apm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Tanmay Inamdar <tinamdar@apm.com>
The pciehp debug logging is overly verbose and often redundant. Almost all
of the information printed by dbg_ctrl() is also printed by the normal PCI
core enumeration code and by pcie_init().
Remove the redundant debug info.
When claiming a pciehp bridge, we print the slot characteristics, e.g.,
Slot #6 AttnBtn- AttnInd- PwrInd- PwrCtrl- MRL- Interlock- NoCompl+ LLActRep+
Add the Hot-Plug Capable and Hot-Plug Surprise bits to this information,
and print it all in the same order as lspci does.
No functional change except the message text changes.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rajat Jain <rajatja@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Use "u32", not "uint32_t", for consistency. Use "tmp", not "temp", for
consistency within the driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Richard Zhu <Richard.Zhu@freescale.com>
Update the Link Control Enable Clock Power Management bit the same
way we update the ASPM Control bits, with a single call of
pcie_capability_clear_and_set_word().
No functional change; this just makes both paths use the same style.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
All the DesignWare-based host drivers loop waiting for the link to come up,
but they do it several ways that are needlessly different.
Wait for the link to come up in a consistent style across all the
DesignWare drivers. No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Pratyush Anand <pratyush.anand@gmail.com>
All other DesignWare-based drivers have a *_establish_link() function.
This functionality is trivial for Layerscape, but factor out a
ls_pcie_establish_link() for consistency with the other drivers. No
functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Pratyush Anand <pratyush.anand@gmail.com>
All the other DesignWare-based drivers use dw_pcie_link_up(), so use it in
this driver, too, for consistency. No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Pratyush Anand <pratyush.anand@gmail.com>
We already use dw_pcie_link_up() once in dra7xx_pcie_establish_link(), but
we duplicate its code later. Use dw_pcie_link_up() for consistency. No
functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Pratyush Anand <pratyush.anand@gmail.com>
The commit referenced below deferred waiting for command completion until
the start of the next command, allowing hardware to do the latching
asynchronously. Unfortunately, being ready to accept a new command is the
only indication we have that the previous command is completed. In cases
where we need that state change to be enabled, we must still wait for
completion. For instance, pciehp_reset_slot() attempts to disable anything
that might generate a surprise hotplug on slots that support presence
detection. If we don't wait for those settings to latch before the
secondary bus reset, we negate any value in attempting to prevent the
spurious hotplug.
Create a base function with optional wait and helper functions so that
pcie_write_cmd() turns back into the "safe" interface which waits before
and after issuing a command and add pcie_write_cmd_nowait(), which
eliminates the trailing wait for asynchronous completion. The following
functions are returned to their previous behavior:
pciehp_power_on_slot
pciehp_power_off_slot
pcie_disable_notification
pciehp_reset_slot
The rationale is that pciehp_power_on_slot() enables the link and therefore
relies on completion of power-on. pciehp_power_off_slot() and
pcie_disable_notification() need a wait because data structures may be
freed after these calls and continued signaling from the device would be
unexpected. And, of course, pciehp_reset_slot() needs to wait for the
scenario outlined above.
Fixes: 3461a06866 ("PCI: pciehp: Wait for hotplug command completion lazily")
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.17+
struct timeval uses a 32-bit field for representing seconds, which
will overflow in the year 2038 and beyond. Replace struct timeval with
64-bit ktime_t which is 2038 safe. This is part of a larger effort to
remove instances of 32-bit timekeeping variables (timeval, time_t and
timespec) from the kernel.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
APM X-Gene v1 SoC supports its own implementation of MSI, which is not
compliant to GIC V2M specification for MSI Termination.
There is a single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
This MSI block supports 2048 MSI termination ports coalesced into 16
physical HW IRQ lines and shared across all 5 PCIe ports.
As there are only 16 HW IRQs to serve 2048 MSI vectors, to support
set_affinity correctly for each MSI vectors, the 16 HW IRQs are statically
allocated to 8 X-Gene v1 cores (2 HW IRQs for each cores). To steer MSI
interrupt to target CPU, MSI vector is moved around these HW IRQs lines.
With this approach, the total MSI vectors this driver supports is reduced
to 256.
[bhelgaas: squash doc, driver, maintainer update]
Signed-off-by: Duc Dang <dhdang@apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Rename imx6_pcie_start_link() to imx6_pcie_establish_link() to follow the
convention of other DesignWare-based host drivers. No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Pratyush Anand <pratyush.anand@gmail.com>
In d74b9027a4 ("PCI: Consider additional PF's IOV BAR alignment in sizing
and assigning"), we store additional alignment in realloc_head and take
this into consideration for assignment.
In __assign_resources_sorted(), we changed dev_res->res->start, then used
resource_start() (which depends on res->start), so the recomputed res->end
was completely bogus. Even if we'd had the correct size, the end would
have been off by one.
Preserve the resource size when we adjust its alignment.
[bhelgaas: changelog]
Fixes: d74b9027a4 ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Wei Yang <weiyang@linux.vnet.ibm.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
David Ahern reported that d63e2e1f3d ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:
pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)
The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3d added new checking that
tripped over this mismatch.
Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3d ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern <david.ahern@oracle.com>
Tested-by: David Ahern <david.ahern@oracle.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
CC: stable@vger.kernel.org # v3.19+
pci_ari_enabled() is useful outside of drivers/pci, particularly for
deriving INTx routing via ACPI _PRT, so move it to the global header.
Also convert to bool return.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Don Dutile <ddutile@redhat.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Previously we assumed that PCIe Root Ports and Downstream Ports had Links
on their secondary side. That is true in most systems, but it is possible
to connect a switch with either an Upstream or a Downstream Port leading
downstream.
Instead of relying on the component type to identify devices that have
links leading downstream, use the "dev->has_secondary_link" field.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The resource list is only used in the setup process and was never freed.
pci_add_resource() allocates a memory area to store the list item.
Fix the memory leak.
Tested-by: Ray Jui <rjui@broadcom.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
The struct iproc_pcie.resources member was pointing to a stack variable and
is invalid after the registration function returned.
Remove this pointer and add a parameter to the function.
Tested-by: Ray Jui <rjui@broadcom.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
In d74b9027a4 ("PCI: Consider additional PF's IOV BAR alignment in sizing
and assigning"), it stores additional alignment in realloc_head and takes
this into consideration for assignment.
After getting the additional alignment, it reorders the head list so
resources with bigger alignment are ahead of resources with smaller
alignment. It does this by iterating over the head list and inserting
ahead of any resource with smaller alignment. This should be done for the
first occurrence, but the code currently iterates over the whole list.
Fix this by terminating the loop when we find the first smaller resource in
the head list.
[bhelgaas: changelog]
Fixes: d74b9027a4 ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning")
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
After b97ea289cf ("PCI: Assign resources before drivers claim devices
(pci_scan_root_bus())"), pci_scan_root_bus() no longer adds the devices, so
it is equivalent to:
pci_create_root_bus()
pci_scan_child_bus()
Use pci_scan_root_bus() to simplify the code.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
CC: Mohit Kumar <mohit.kumar@st.com>
After b97ea289cf ("PCI: Assign resources before drivers claim devices
(pci_scan_root_bus())"), pci_scan_root_bus() no longer adds the devices, so
it is equivalent to tegra_pcie_scan_bus().
Remove tegra_pcie_scan_bus() (the hw.scan method), so we use the generic
pci_scan_root_bus() path.
[bhelgaas: changelog]
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thierry Reding <treding@nvidia.com>
After b97ea289cf ("PCI: Assign resources before drivers claim devices
(pci_scan_root_bus())"), pci_scan_root_bus() no longer adds the devices, so
it is equivalent to mvebu_pcie_scan_bus().
Remove mvebu_pcie_scan_bus() (the hw.scan method), so we use the generic
pci_scan_root_bus() path. We also need to use pci_common_init_dev()
instead of pci_common_init() so we can supply the host bridge device
pointer.
[bhelgaas: changelog]
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Jason Cooper <jason@lakedaemon.net>
We allocate pcie_link_state for the component at the upstream end of a
Link. Previously we did this by allocating pcie_link_state for Root Ports
and Downstream Ports. This works fine for the typical topology:
00:1c.0 Root Port [bridge to bus 02]
02:00.0 Upstream Port [bridge to bus 03]
03:00.0 Downstream Port [bridge to bus 04]
04:00.0 Endpoint or Switch Port
However, it is possible to have a Root Port connected to a Downstream Port
instead of an Upstream Port, as in Robert White's ATCA system:
00:1c.0 Root Port [bridge to bus 02]
02:00.0 Downstream Port [bridge to bus 03]
03:01.0 Downstream Port [bridge to bus 04]
04:00.0 Endpoint or Switch Port
In this topology, we wrongly allocated pcie_link_state for the 02:00.0
Downstream Port, which is actually the *downstream* end of a link. This
led to the following NULL pointer dereference when we tried to connect this
link into the tree of links starting at the 00:1c.0 Root Port:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
IP: [<ffffffff81550324>] pcie_aspm_init_link_state+0x744/0x850
Hardware name: Kontron B3001/B3001, BIOS 4.6.3 08/07/2012
Call Trace:
[<ffffffff8153b865>] pci_scan_slot+0xd5/0x120
[<ffffffff8153ca1d>] pci_scan_child_bus+0x2d/0xd0
...
Instead of relying on the component type to identify the upstream end of a
link, use the "dev->has_secondary_link" field.
This means it's now possible for an Upstream Port to have a link on its
secondary side, so alloc_pcie_link_state() needs to connect links
originating from both Upstream and Downstream Ports into the tree.
[bhelgaas: changelog, add comment]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Reported-by: Robert White <rwhite@pobox.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If the ignore_hotplug flag is set for a PCI device without an ACPI
companion and a bus check notification is received for an ancestor bridge
that is not the device's parent, ACPIPHP will ignore that flag.
Namely, in that case acpiphp_check_bridge() is called for the target bridge
and if all of the devices immediately below the bridge are still present,
trim_stale_devices() will be called for each of them. That function
recursively walks the hierarchy downwards and removes device objects
corresponding to devices that don't appear to be present any more.
Unfortunately, it only checks ignore_hotplug for devices having ACPI
companions, so it will remove the others (if they don't respond) regardless
of the ignore_hotplug value.
Fix the problem by making trim_stale_devices() take ignore_hotplug into
consideration regardless of whether or not an ACPI companion is present for
the device it has been called for.
[bhelgaas: This may fix bug 61891, depending on whether the bridge above a
device is removed along with the device]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The err_out_none label in pciehp_probe() only leads to a return statement,
so use return statements instead of jumps to it and drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
A PCIe Port is an interface to a Link. A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side. For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.
The usual topology has a Root Port connected to an Upstream Port. We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:
+---------------------+
+------+ | Downstream |
| Root | | Upstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port. In this case, a Downstream Port's Link may be on either
the upstream or downstream side:
+---------------------+
+------+ | Upstream |
| Root | | Downstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.
A Root Port's Link is always on the Port's secondary side. A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side. If that component is a Port, it is part of a Switch or
a Bridge. A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link. The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.
[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Marvell 9120 SATA controller has the same issue as a number of others, so
use the same quirk for this one. The other quirks were added by
cc346a4714 ("PCI: Add function 1 DMA alias quirk for Marvell devices").
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Jarod Wilson reports that ExpressCard hotplug doesn't work on HP ZBook G2.
The problem turns out to be the ACPI-based "slot detection" code called
from pciehp_probe() which uses questionable heuristics based on what ACPI
objects are present for the PCIe port device to figure out whether to
register a hotplug slot for that port.
That code is used if there is at least one PCIe port having an ACPI device
configuration object related to hotplug (such as _EJ0 or _RMV), and the
Thunderbolt port on the ZBook has _RMV. Of course, Thunderbolt and PCIe
native hotplug need not be mutually exclusive (as they aren't on the
ZBook), so that rule is simply incorrect.
Moreover, the ACPI-based "slot detection" check does not add any value if
pciehp_probe() is called at all and the service type of the device object
it has been called for is PCIE_PORT_SERVICE_HP, because PCIe hotplug
services are only registered if the _OSC handshake in acpi_pci_root_add()
allows the kernel to control the PCIe native hotplug feature. No more
checks need to be carried out to decide whether or not to register a native
PCIe hotlug slot in that case.
For the above reasons, make pciehp_probe() check if it has been called for
the right service type and drop the pointless ACPI-based "slot detection"
check from it. Also remove the entire code whose only user is that check
(the entire pciehp_acpi.c file goes away as a result) and drop function
headers related to it from the internal pciehp header file.
Link: http://lkml.kernel.org/r/1431632038-39917-1-git-send-email-jarod@redhat.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98581
Reported-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Currently, the outbound iATU programming functions are similar: the only
difference is index, type, addr and size. Consolidate these functions into
one. This saves about 1700 bytes in text:
text data bss dec hex filename
9276 204 4 9484 250c pcie-designware.o-before
7532 204 4 7740 1e3c pcie-designware.o
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Pratyush Anand <pratyush.anand@gmail.com>
We decide in alloc_pcie_link_state() whether to allocate a pcie_link_state
for a device. After that, it's sufficient to check pdev->link_state. We
don't need to check the PCIe port type again.
Remove the redundant PCIe port type checking.
[bhelgaas: changelog]
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
After 387d37577f ("PCI: Don't clear ASPM bits when the FADT declares it's
unsupported"), the "force" parameter to __pci_disable_link_state() is
always "false".
Remove the "force" parameter and assume it's always false.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This driver adds support for the PCIe 2.0 controller found on the BCMA bus.
This controller can be found on (mostly) all Broadcom BCM470X / BCM5301X
ARM SoCs.
The driver found in the Broadcom SDK does some more stuff, like setting up
some DMA memory areas, chaining MPS and MRRS to 512 and also some PHY
changes like "improving" the PCIe jitter and doing some special
initialization for the 3rd PCIe port.
This was tested on a bcm4708 board with 2 PCIe ports and wireless cards
connected to them.
PCI_DOMAINS is needed by this driver, because normally there is more than
one PCIe controller and without PCI_DOMAINS only the first controller gets
registered. This controller gets 6 IRQs; the last one is trigged by all
IRQ events.
[bhelgaas: fix "GPLv2" MODULE_LICENSE typo]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Ray Jui <rjui@broadcom.com.com>
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>
Intel confirms that 9-series chipset root ports provide ACS-equivalent
isolation when configured via the existing Intel PCH ACS quirk setup.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
The PCI core now disables MSI and MSI-X for all devices during enumeration
regardless of CONFIG_PCI_MSI. Remove device-specific code to disable
MSI/MSI-X.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
If we enable MSI, then kexec a new kernel, the new kernel may receive MSIs
it is not prepared for. Commit d5dea7d95c ("PCI: msi: Disable msi
interrupts when we initialize a pci device") prevents this, but only if the
new kernel is built with CONFIG_PCI_MSI=y.
Move the "disable MSI" functionality from drivers/pci/msi.c to a new
pci_msi_setup_pci_dev() in drivers/pci/probe.c so we can disable MSIs when
we enumerate devices even if the kernel doesn't include full MSI support.
[bhelgaas: changelog, disable MSIs in pci_setup_device(), put
pci_msi_setup_pci_dev() at its final destination]
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move pci_msi_set_enable() and pci_msix_clear_and_set_ctrl() to
drivers/pci/pci.h so they're available even when MSI isn't configured
into the kernel.
No functional change.
[bhelgaas: changelog, split into separate patch]
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Rename msi_set_enable() to pci_msi_set_enable() and
msix_clear_and_set_ctrl() to pci_msix_clear_and_set_ctrl().
No functional change.
[bhelgaas: changelog, split into separate patch]
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
