- 03 Oct, 2016 8 commits
-
-
Bjorn Helgaas authored
* pci/virtualization: PCI: xilinx: Relax device number checking to allow SR-IOV PCI: designware: Relax device number checking to allow SR-IOV PCI: altera: Relax device number checking to allow SR-IOV PCI: Check for pci_setup_device() failure in pci_iov_add_virtfn() PCI: Mark Atheros AR9580 to avoid bus reset
-
Bjorn Helgaas authored
* pci/resource: PCI: Ignore requested alignment for VF BARs PCI: Ignore requested alignment for PROBE_ONLY and fixed resources
-
Bjorn Helgaas authored
* pci/pm: PCI: Avoid unnecessary resume after direct-complete PCI: Recognize D3cold in pci_update_current_state() PCI: Query platform firmware for device power state PCI: Afford direct-complete to devices with non-standard PM
-
Bjorn Helgaas authored
* pci/msi: PCI/MSI: Enable PCI_MSI_IRQ_DOMAIN support for ARC
-
Bjorn Helgaas authored
* pci/misc: PCI: Drop CONFIG_KEXEC_CORE ifdeffery
-
Bjorn Helgaas authored
* pci/hotplug: x86/PCI: VMD: Request userspace control of PCIe hotplug indicators PCI: pciehp: Allow exclusive userspace control of indicators PCI: pciehp: Remove useless pciehp_get_latch_status() calls PCI: pciehp: Clean up dmesg "Slot(%s)" messages PCI: pciehp: Remove unnecessary guard PCI: pciehp: Don't re-read Slot Status when handling surprise event PCI: pciehp: Don't re-read Slot Status when queuing hotplug event PCI: pciehp: Process all hotplug events before looking for new ones PCI: pciehp: Return IRQ_NONE when we can't read interrupt status PCI: pciehp: Rename pcie_isr() locals for clarity PCI: pciehp: Clear attention LED on device add
-
Bjorn Helgaas authored
* pci/enumeration: PCI: tegra: Fix pci_remap_iospace() failure path PCI: generic: Fix pci_remap_iospace() failure path PCI: rcar: Fix pci_remap_iospace() failure path PCI: versatile: Fix pci_remap_iospace() failure path PCI: designware: Fix pci_remap_iospace() failure path PCI: aardvark: Fix pci_remap_iospace() failure path
-
Bjorn Helgaas authored
* pci/aer: PCI/AER: Fix aer_probe() kernel-doc comment PCI/AER: Cache capability position PCI/AER: Avoid memory allocation in interrupt handling path ACPI / APEI: Send correct severity to calculate AER severity PCI/AER: Remove duplicate AER severity translation PCI/AER: Remove aerdriver.forceload kernel parameter PCI/AER: Remove aerdriver.nosourceid kernel parameter x86/PCI: VMD: Add quirk for AER to ignore source ID PCI/AER: Add bus flag to skip source ID matching Conflicts: drivers/pci/probe.c
-
- 30 Sep, 2016 1 commit
-
-
Cao jin authored
0516c8bc ("PCI: PCIe portdrv: Simplily probe callback of service drivers") removed the "id" argument of aer_probe() but neglected to remove the kernel-doc comment. Update the comment. [bhelgaas: changelog] Signed-off-by:
Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
- 28 Sep, 2016 6 commits
-
-
Yongji Xie authored
Resource allocation for VFs is done via the VF BARx registers in the PF's SR-IOV Capability, and the BARs in the VFs themselves are read-only zeros (see SR-IOV spec r1.1, secs 3.3.14 and 3.4.1.11). Even though the actual VF BARs are read-only zeros, the VF dev->resource[] structs describe the space allocated for the VF (this is a piece of the space described by the VF BARx register in the PF's SR-IOV capability). It's meaningless to request additional alignment for a VF: the VF BAR alignment is completely determined by the alignment of the VF BARx in the PF and the size of the VF BAR. Ignore the user's alignment requests for VF devices. Signed-off-by:
Yongji Xie <xyjxie@linux.vnet.ibm.com> Signed-off-by:
-
Yongji Xie authored
Users may request additional alignment of PCI resources, e.g., to align BARs on page boundaries so they can be shared with guests via VFIO. This of course may require reallocation if firmware has already assigned the BARs with smaller alignments. If the platform has requested PCI_PROBE_ONLY, we should never change any PCI BARs, so we can't provide any additional alignment. Also, if a BAR is marked as IORESOURCE_PCI_FIXED, e.g., for PCI Enhanced Allocation or if the firmware depends on the current BAR value, we can't change the alignment. In these cases, log a message and ignore the user's alignment requests. [bhelgaas: changelog, use goto to simplify PCI_PROBE_ONLY check] Signed-off-by:
-
Lukas Wunner authored
Commit 58a1fbbb ("PM / PCI / ACPI: Kick devices that might have been reset by firmware") added a runtime resume for devices that were runtime suspended when the system entered sleep. The motivation was that devices might be in a reset-power-on state after waking from system sleep, so their power state as perceived by Linux (stored in pci_dev->current_state) would no longer reflect reality. By resuming such devices, we allow them to return to a low-power state via autosuspend and also bring their current_state in sync with reality. However for devices that are *not* in a reset-power-on state, doing an unconditional resume wastes energy. A more refined approach is called for which issues a runtime resume only if the power state after direct-complete is shallower than it was before. To achieve this, update the device's current_state and compare it to its pre-sleep value. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lukas Wunner authored
Whenever a device is resumed or its power state is changed using the platform, its new power state is read from the PM Control & Status Register and cached in pci_dev->current_state by calling pci_update_current_state(). If the device is in D3cold, reading from config space typically results in a fabricated "all ones" response. But if it's in D3hot, the two bits representing the power state in the PMCSR are *also* set to 1. Thus D3hot and D3cold are not discernible by just reading the PMCSR. To account for this, pci_update_current_state() uses two workarounds: - When transitioning to D3cold using pci_platform_power_transition(), the new power state is set blindly by pci_update_current_state(), i.e. without verifying that the device actually *is* in D3cold. This is achieved by setting the "state" argument to PCI_D3cold. The "state" argument was originally intended to convey the new state in case the device doesn't have the PM capability. It is *also* used to convey the device state if the PM capability is present and the new state is D3cold, but this was never explained in the kerneldoc. - Once the current_state is set to D3cold, further invocations of pci_update_current_state() will blindly assume that the device is still in D3cold and leave the current_state unmodified. To get out of this impasse, the current_state has to be set directly, typically by calling pci_raw_set_power_state() or pci_enable_device(). It would be desirable if pci_update_current_state() could reliably detect D3cold by itself. That would allow us to do away with these workarounds, and it would allow for a smarter, more energy conserving runtime resume strategy after system sleep: Currently devices which utilize direct_complete are mandatorily runtime resumed in their ->complete stage. This can be avoided if their power state after system sleep is the same as before, but it requires a mechanism to detect the power state reliably. We've just gained the ability to query the platform firmware for its opinion on the device's power state. On platforms conforming to ACPI 4.0 or newer, this allows recognition of D3cold. Pre-4.0 platforms lack _PR3 and therefore the deepest power state that will ever be reported is D3hot, even though the device may actually be in D3cold. To detect D3cold in those cases, accessibility of the vendor ID in config space is probed using pci_device_is_present(). This also works for devices which are not platform-power-manageable at all, but can be suspended to D3cold using a nonstandard mechanism (e.g. some hybrid graphics laptops or Thunderbolt on the Mac). Signed-off-by:
-
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 authored
There are devices not power-manageable by the platform, but still able to runtime suspend to D3cold with a non-standard mechanism. One example is laptop hybrid graphics where the discrete GPU and its built-in HDA controller are power-managed either with a _DSM (AMD PowerXpress, Nvidia Optimus) or a separate gmux controller (MacBook Pro). Another example is Thunderbolt on Macs which is power-managed with custom ACPI methods. When putting the system to sleep, we currently handle such devices improperly by transitioning them from D3cold to D3hot (the default power state defined at the top of pci_target_state()). This wastes energy and prolongs the suspend sequence (powering up the Thunderbolt controller takes 2 seconds). Avoid that by assuming that a non-standard PM mechanism is at work if the device is not platform-power-manageable but currently in D3cold. If the device is wakeup enabled, we might still have to wake it up from D3cold if PME cannot be signaled from that power state. The check for devices without PM capability comes before the check for D3cold since such devices could in theory also be powered down by non-standard means and should then be afforded direct-complete as well. Signed-off-by:
-
- 27 Sep, 2016 2 commits
-
-
Keith Busch authored
Save the position of the error reporting capability so it doesn't need to be rediscovered during error handling. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Jon Derrick authored
When handling AER events, we previously allocated a struct aer_err_info, processed the error, and freed the struct. But aer_isr_one_error() is serialized by rpc_mutex, so we never need more than one copy of the struct, and the struct is only about 70 bytes, so we're not saving much by allocating it dynamically. Embed a struct aer_err_info directly in struct aer_rpc, which is allocated at probe-time by aer_probe(). [bhelgaas: changelog] Suggested-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
-
- 23 Sep, 2016 1 commit
-
-
Keith Busch authored
Add set_dev_domain_options() to set PCI domain-specific options as devices are added. The first usage is to request exclusive userspace control of PCIe hotplug indicators in VMD domains. Devices in a VMD domain use PCIe hotplug Attention and Power Indicators in a non-standard way; tell pciehp to ignore the indicators so userspace can control them via the sysfs "attention" file. To determine whether a bus is within a VMD domain, add a bool to the pci_sysdata structure that the VMD driver sets during initialization. [bhelgaas: changelog] Requested-by:
Kapil Karkra <kapil.karkra@intel.com> Tested-by:
Artur Paszkiewicz <artur.paszkiewicz@intel.com> Signed-off-by:
-
- 22 Sep, 2016 1 commit
-
-
Keith Busch authored
PCIe hotplug supports optional Attention and Power Indicators, which are used internally by pciehp. Users can't control the Power Indicator, but they can control the Attention Indicator by writing to a sysfs "attention" file. The Slot Control register has two bits for each indicator, and the PCIe spec defines the encodings for each as (Reserved/On/Blinking/Off). For sysfs "attention" writes, pciehp_set_attention_status() maps into these encodings, so the only useful write values are 0 (Off), 1 (On), and 2 (Blinking). However, some platforms use all four bits for platform-specific indicators, and they need to allow direct user control of them while preventing pciehp from using them at all. Add a "hotplug_user_indicators" flag to the pci_dev structure. When set, pciehp does not use either the Attention Indicator or the Power Indicator, and the low four bits (values 0x0 - 0xf) of sysfs "attention" write values are written directly to the Attention Indicator Control and Power Indicator Control fields. [bhelgaas: changelog, rename flag and accessors to s/attention/indicator/] Signed-off-by:
-
- 20 Sep, 2016 2 commits
-
-
Tyler Baicar authored
Currently the AER severity is calculated by calling cper_severity_to_aer(), but the parameter sent is actually the GHES severity. This causes the AER severity to be incorrect. Fix the parameter to be the CPER severity instead of the GHES severity. Signed-off-by:
Tyler Baicar <tbaicar@codeaurora.org> Signed-off-by:
Borislav Petkov <bp@suse.de>
-
Tyler Baicar authored
Currently the AER severity is being translated twice in the code flow for PCIe errors. It is first translated in ghes_do_proc() before calling into the AER driver. Then it is translated again when the AER driver calls cper_print_aer(). This causes the severity that is used in cper_print_aer() to be incorrect. Remove the second translation that is in cper_print_aer() since this function is already receiving the correct AER severity. Signed-off-by:
-
- 14 Sep, 2016 9 commits
-
-
Bjorn Helgaas authored
Per the PCI Firmware spec, r3.0, sec 4.5.1, on ACPI systems, the OS must not use AER unless _OSC is present and _OSC grants AER control to the OS. The aerdriver.forceload kernel parameter was a way to enable Linux AER support on ACPI systems that lack _OSC or fail to grant control the the OS. Enabling Linux AER support when the firmware doesn't want us to is a recipe for problems, e.g., the firmware might be handling AER itself. Remove the aerdriver.forceload kernel parameter and related supporting code. Signed-off-by: -
Bjorn Helgaas authored
The aerdriver.nosourceid kernel parameter was intended for working around broken chipsets don't supply the source ID for AER events. We recently added PCI_BUS_FLAGS_NO_AERSID, which can be set by quirks for the same purpose. Remove the aerdriver.nosourceid kernel parameter. For anything other than debugging, asking users to find and use kernel parameters is a poor user experience. Instead, we should add PCI_BUS_FLAGS_NO_AERSID quirks for any hardware that needs it. Signed-off-by: -
Bjorn Helgaas authored
Long ago, we updated a "switch_save" field based on the latch status. But switch_save was unused, and ed6cbcf2 ("[PATCH] pciehp: miscellaneous cleanups") removed it. We no longer use the latch status, so remove calls to pciehp_get_latch_status(). No functional change intended. Tested-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
Bjorn Helgaas authored
Print slot name consistently as "Slot(%s)". I don't know whether that's ideal, but we can at least do it the same way all the time. No functional change intended. Tested-by:
-
Bjorn Helgaas authored
In pcie_isr(), we return early if no status bits other than PCI_EXP_SLTSTA_CC are set. This was introduced by dbd79aed ("pciehp: fix NULL dereference in interrupt handler"), but it is no longer necessary because all the subsequent pcie_isr() code is already predicated on a status bit being set. Remove the unnecessary test for ~PCI_EXP_SLTSTA_CC. No functional change intended. Tested-by:
-
Mayurkumar Patel authored
Previously we read Slot Status when handling a surprise event. But Slot Status might have changed since we identified the event, and the event_type already tells us whether to enable or disable the slot, so there's no need to read it again. Remove handle_surprise_event() and queue the power work directly. [bhelgaas: changelog] Tested-by:
Mayurkumar Patel <mayurkumar.patel@intel.com> Signed-off-by:
Rajat Jain <rajatxjain@gmail.com>
-
Mayurkumar Patel authored
Previously we read Slot Status to learn about hotplug events, then cleared the events, then re-read Slot Status to find out what happened. But Slot Status might have changed before the second read. Capture the Slot Status once before clearing the events. Also capture the Link Status if we had a link status change. [bhelgaas: changelog, split to separate patch] Tested-by:
-
Mayurkumar Patel authored
Previously we accumulated hotplug events, then processed them, essentially like this: events = 0 do { status = read(Slot Status) status &= EVENT_MASK # only look at events events |= status # accumulate events write(Slot Status, events) # clear events } while (status) process events The problem is that as soon as we clear events in Slot Status, the hardware may send notifications for new events, and we lose information about the first events. For example, we might see two Presence Detect Changed events, but lose the fact that the slot was temporarily empty: read PCI_EXP_SLTSTA_PDC set, PCI_EXP_SLTSTA_PDS clear # slot empty write PCI_EXP_SLTSTA_PDC # clear PDC event read PCI_EXP_SLTSTA_PDC set, PCI_EXP_SLTSTA_PDS set # slot occupied The current code does not process a removal; it only processes the insertion, which fails because we didn't remove the original device. To avoid this problem, read Slot Status once and process all the events before reading it again, like this: do { read events clear events process events } while (events) [bhelgaas: changelog, add external loop around pciehp_isr()] Tested-by: -
Bjorn Helgaas authored
After 1469d17d ("PCI: pciehp: Handle invalid data when reading from non-existent devices"), we returned IRQ_HANDLED when we failed to read interrupt status from the bridge. I think it's better to return IRQ_NONE, as we do in other cases where there's no interrupt pending. This will facilitate refactoring the loop in pcie_isr(): we'll be able to call the ISR in a loop as long as it returns IRQ_HANDLED. Return IRQ_NONE if we couldn't read interrupt status. Tested-by:
-
- 12 Sep, 2016 5 commits
-
-
Po Liu authored
Previously we only allowed device 0 to be directly attached to the root port. But SR-IOV devices may use non-zero device numbers for VFs. Remove the restriction that only device 0 may be attached to a root port. [bhelgaas: changelog] Signed-off-by:
Po Liu <po.liu@nxp.com> Signed-off-by:
-
Po Liu authored
Previously we only allowed device 0 to be directly attached to the root port. But SR-IOV devices may use non-zero device numbers for VFs. Remove the restriction that only device 0 may be attached to a root port. [bhelgaas: changelog] Signed-off-by:
Jingoo Han <jingoohan1@gmail.com>
-
Po Liu authored
Previously we only allowed device 0 to be directly attached to the root port. But SR-IOV devices may use non-zero device numbers for VFs. Remove the restriction that only device 0 may be attached to a root port. [bhelgaas: changelog] Signed-off-by:
Ley Foon Tan <lftan@altera.com>
-
Po Liu authored
If pci_setup_device() returns failure, we must return failure from pci_iov_add_virtfn(). If we ignore the failure and continue with an uninitialized pci_dev for virtfn, we crash later when we try to use those uninitialized parts. Signed-off-by:
-
Bjorn Helgaas authored
Rename "detected" and "intr_loc" to "status" and "events" for clarity. "status" is the value we read from the Slot Status register; "events" is the set of hot-plug events we need to process. No functional change intended. Tested-by:
-
- 06 Sep, 2016 5 commits
-
-
Jon Derrick authored
VMD root ports change all source ids to the VMD device ID. To find the sender of the AER notification, we need to scan all child devices for the AER sender, rather than relying on the source ID from the message. Signed-off-by:
-
Jon Derrick authored
Allow root port buses to choose to skip source id matching when finding the faulting device. Certain root port devices may return an incorrect source ID and recommend to scan child device registers for AER notifications. Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI tegra host bridge driver adds the PCI IO resource retrieved from firmware to the host bridge resource windows even if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Add the PCI host bridge driver pci_remap_iospace() failure path and do not add the corresponding PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, fixing the issue. Fixes: e6e9f471 ("PCI: tegra: Use generic pci_remap_iospace() rather than ARM32-specific one") Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI common host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 4e64dbe2 ("PCI: generic: Expose pci_host_common_probe() for use by other drivers") Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Lorenzo Pieralisi authored
On ARM/ARM64 architectures, PCI IO ports are emulated through memory mapped IO, by reserving a chunk of virtual address space starting at PCI_IOBASE and by mapping the PCI host bridges memory address space driving PCI IO cycles to it. PCI host bridge drivers that enable downstream PCI IO cycles map the host bridge memory address responding to PCI IO cycles to the fixed virtual address space through the pci_remap_iospace() API. This means that if the pci_remap_iospace() function fails, the corresponding host bridge PCI IO resource must be considered invalid, in that there is no way for the kernel to actually drive PCI IO transactions if the memory addresses responding to PCI IO cycles cannot be mapped into the CPU virtual address space. The PCI rcar host bridge driver does not remove the PCI IO resource from the host bridge resource windows if the pci_remap_iospace() call fails; this is an actual bug in that the PCI host bridge would consider the PCI IO resource valid (and possibly assign it to downstream devices) even if the kernel was not able to map the PCI host bridge memory address driving IO cycle to the CPU virtual address space (ie pci_remap_iospace() failures). Fix the PCI host bridge driver pci_remap_iospace() failure path, by destroying the PCI host bridge PCI IO resources retrieved through firmware when the pci_remap_iospace() function call fails, therefore preventing the kernel from adding the respective PCI IO resource to the list of PCI host bridge valid resources, fixing the issue. Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API") Signed-off-by:
-
