summaryrefslogtreecommitdiffstats
path: root/drivers/pci/pci.h
Commit message (Collapse)AuthorAgeFilesLines
* PCI: Export ACPI _DSM provided firmware instance number and string name to sysfsNarendra_K@Dell.com2011-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch exports ACPI _DSM (Device Specific Method) provided firmware instance number and string name of PCI devices as defined by 'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming a PCI or PCI Express Device Under Operating Systems) to sysfs. New files created are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../acpi_index which contains the firmware device type instance for the given device. cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index 1 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label Embedded Broadcom 5709C NIC 1 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index 2 cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label Embedded Broadcom 5709C NIC 2 The ACPI _DSM provided firmware 'instance number' and 'string name' will be given priority if the firmware also provides 'SMBIOS type 41 device type instance and string'. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI/PM: Use pm_wakeup_event() directly for reporting wakeup eventsRafael J. Wysocki2011-01-141-0/+6
| | | | | | | | | | After recent changes related to wakeup events pm_wakeup_event() automatically checks if the given device is configured to signal wakeup, so pci_wakeup_event() may be a static inline function calling pm_wakeup_event() directly. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI/ACPI: Request _OSC control once for each root bridge (v3)Rafael J. Wysocki2011-01-141-8/+0
| | | | | | | | | | | | | | Move the evaluation of acpi_pci_osc_control_set() (to request control of PCI Express native features) into acpi_pci_root_add() to avoid calling it many times for the same root complex with the same arguments. Additionally, check if all of the requisite _OSC support bits are set before calling acpi_pci_osc_control_set() for a given root complex. References: https://bugzilla.kernel.org/show_bug.cgi?id=20232 Reported-by: Ozan Caglayan <ozan@pardus.org.tr> Tested-by: Ozan Caglayan <ozan@pardus.org.tr> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: fix size checks for mmap() on /proc/bus/pci filesMartin Wilck2010-11-111-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The checks for valid mmaps of PCI resources made through /proc/bus/pci files that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several problems: 1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0, whereas under /sys/bus/pci/devices, the start of the resource corresponds to offset 0. This may lead to false negatives in pci_mmap_fits(), which implicitly assumes the /sys/bus/pci/devices layout. 2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads to false positives, because pci_mmap_fits() doesn't treat empty resources correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT) in this case!). 3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus WARNINGS for the first resources that don't fit until the correct one is found. On many controllers the first 2-4 BARs are used, and the others are empty. In this case, an mmap attempt will first fail on the non-empty BARs (including the "right" BAR because of 1.) and emit bogus WARNINGS because of 3., and finally succeed on the first empty BAR because of 2. This is certainly not the intended behaviour. This patch addresses all 3 issues. Updated with an enum type for the additional parameter for pci_mmap_fits(). Cc: stable@kernel.org Signed-off-by: Martin Wilck <martin.wilck@ts.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Export some PCI PM functionalityMatthew Garrett2010-10-171-3/+0
| | | | | | | | | It's helpful to have some extra PCI power management functions available to platform code, so move the declarations to an exported header. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: fix pci_resource_alignment prototypeCam Macdonell2010-09-091-2/+3
| | | | | | | | | | | | | This fixes the prototype for both pci_resource_alignment() and pci_sriov_resource_alignment(). Patch started as debugging effort from Cam Macdonell. Cc: Cam Macdonell <cam@cs.ualberta.ca> Cc: Avi Kivity <avi@redhat.com> [chrisw: add iov bits] Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: PCIe AER: Introduce pci_aer_available()Rafael J. Wysocki2010-08-241-0/+2
| | | | | | | | Introduce a function allowing the caller to check whether to try to enable PCIe AER. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* Merge branch 'linux-next' of ↵Linus Torvalds2010-08-061-0/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (30 commits) PCI: update for owner removal from struct device_attribute PCI: Fix warnings when CONFIG_DMI unset PCI: Do not run NVidia quirks related to MSI with MSI disabled x86/PCI: use for_each_pci_dev() PCI: use for_each_pci_dev() PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc() PCI: export SMBIOS provided firmware instance and label to sysfs PCI: Allow read/write access to sysfs I/O port resources x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLAN PCI: remove unused HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_{SIZE|BOUNDARY} PCI: disable mmio during bar sizing PCI: MSI: Remove unsafe and unnecessary hardware access PCI: Default PCIe ASPM control to on and require !EMBEDDED to disable PCI: kernel oops on access to pci proc file while hot-removal PCI: pci-sysfs: remove casts from void* ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe PCI hotplug: make sure child bridges are enabled at hotplug time PCI hotplug: shpchp: Removed check for hotplug of display devices PCI hotplug: pciehp: Fixed return value sign for pciehp_unconfigure_device PCI: Don't enable aspm before drivers have had a chance to veto it ...
| * PCI: Fix warnings when CONFIG_DMI unsetNarendra K2010-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the below warnings introduced by the commit 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided firmware instance and label to sysfs"). drivers/pci/pci.h: In function ‘pci_create_firmware_label_files’: drivers/pci/pci.h:16: warning: ‘return’ with a value, in function returning void drivers/pci/pci.h: In function ‘pci_remove_firmware_label_files’: drivers/pci/pci.h:18: warning: ‘return’ with a value, in function returning void The warnings are seen because of the below code, doing a retun 0 from the functions 'pci_create_firmware_label_files' and 'pci_remove_firmware_label_files' defined as void. +#ifndef CONFIG_DMI +static inline void pci_create_firmware_label_files(struct pci_dev *pdev) +{ return 0; } +static inline void pci_remove_firmware_label_files(struct pci_dev *pdev) +{ return 0; } Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: export SMBIOS provided firmware instance and label to sysfsNarendra K2010-07-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch exports SMBIOS provided firmware instance and label of onboard PCI devices to sysfs. New files are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../index which contains the firmware device type instance for the given device. Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com> Signed-off-by: Narendra K <narendra_k@dell.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | PM: Make it possible to avoid races between wakeup and system sleepRafael J. Wysocki2010-07-191-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the arguments during the suspend blockers discussion was that the mainline kernel didn't contain any mechanisms making it possible to avoid races between wakeup and system suspend. Generally, there are two problems in that area. First, if a wakeup event occurs exactly when /sys/power/state is being written to, it may be delivered to user space right before the freezer kicks in, so the user space consumer of the event may not be able to process it before the system is suspended. Second, if a wakeup event occurs after user space has been frozen, it is not generally guaranteed that the ongoing transition of the system into a sleep state will be aborted. To address these issues introduce a new global sysfs attribute, /sys/power/wakeup_count, associated with a running counter of wakeup events and three helper functions, pm_stay_awake(), pm_relax(), and pm_wakeup_event(), that may be used by kernel subsystems to control the behavior of this attribute and to request the PM core to abort system transitions into a sleep state already in progress. The /sys/power/wakeup_count file may be read from or written to by user space. Reads will always succeed (unless interrupted by a signal) and return the current value of the wakeup events counter. Writes, however, will only succeed if the written number is equal to the current value of the wakeup events counter. If a write is successful, it will cause the kernel to save the current value of the wakeup events counter and to abort the subsequent system transition into a sleep state if any wakeup events are reported after the write has returned. [The assumption is that before writing to /sys/power/state user space will first read from /sys/power/wakeup_count. Next, user space consumers of wakeup events will have a chance to acknowledge or veto the upcoming system transition to a sleep state. Finally, if the transition is allowed to proceed, /sys/power/wakeup_count will be written to and if that succeeds, /sys/power/state will be written to as well. Still, if any wakeup events are reported to the PM core by kernel subsystems after that point, the transition will be aborted.] Additionally, put a wakeup events counter into struct dev_pm_info and make these per-device wakeup event counters available via sysfs, so that it's possible to check the activity of various wakeup event sources within the kernel. To illustrate how subsystems can use pm_wakeup_event(), make the low-level PCI runtime PM wakeup-handling code use it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: markgross <markgross@thegnar.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
* PCI: make bitfield unsignedBill Pemberton2010-05-111-1/+1
| | | | | | | | | | Fix sparse warning: drivers/pci/pci.h:247:25: error: dubious one-bit signed bitfield Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> CC: linux-pci@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* PCI PM: Run-time callbacks for PCI bus typeRafael J. Wysocki2010-02-221-0/+1
| | | | | | | | | | | Introduce run-time PM callbacks for the PCI bus type. Make the new callbacks work in analogy with the existing system sleep PM callbacks, so that the drivers already converted to struct dev_pm_ops can use their suspend and resume routines for run-time PM without modifications. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI / ACPI / PM: Platform support for PCI PME wake-upRafael J. Wysocki2010-02-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the majority of PCI devices can generate PMEs that in principle may be used to wake up devices suspended at run time, platform support is generally necessary to convert PMEs into wake-up events that can be delivered to the kernel. If ACPI is used for this purpose, PME signals generated by a PCI device will trigger the ACPI GPE associated with the device to generate an ACPI wake-up event that we can set up a handler for, provided that everything is configured correctly. Unfortunately, the subset of PCI devices that have GPEs associated with them is quite limited. The devices without dedicated GPEs have to rely on the GPEs associated with other devices (in the majority of cases their upstream bridges and, possibly, the root bridge) to generate ACPI wake-up events in response to PME signals from them. Add ACPI platform support for PCI PME wake-up: o Add a framework making is possible to use ACPI system notify handlers for run-time PM. o Add new PCI platform callback ->run_wake() to struct pci_platform_pm_ops allowing us to enable/disable the platform to generate wake-up events for given device. Implemet this callback for the ACPI platform. o Define ACPI wake-up handlers for PCI devices and PCI root buses and make the PCI-ACPI binding code register wake-up notifiers for all PCI devices present in the ACPI tables. o Add function pci_dev_run_wake() which can be used by PCI drivers to check if given device is capable of generating wake-up events at run time. Developed in cooperation with Matthew Garrett <mjg@redhat.com>. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI PM: Add function for checking PME status of devicesRafael J. Wysocki2010-02-221-0/+1
| | | | | | | | | | | Add function pci_check_pme_status() that will check the PME status bit of given device and clear it along with the PME enable bit. It will be necessary for PCI run-time power management. Based on a patch from Shaohua Li <shaohua.li@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Clean up build for CONFIG_PCI_QUIRKS unsetRafael J. Wysocki2010-02-221-0/+7
| | | | | | | | | | | | | | | | | | | Currently, drivers/pci/quirks.c is built unconditionally, but if CONFIG_PCI_QUIRKS is unset, the only things actually built in this file are definitions of global variables and empty functions (due to the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the file). This is not particularly nice and if someone overlooks the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced. To clean that up, move the definitions of the global variables in quirks.c that are always built to pci.c, move the definitions of the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to headers (additionally make these functions static inline) and modify drivers/pci/Makefile so that quirks.c is only built if CONFIG_PCI_QUIRKS is set. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Fix build if quirks are not enabledRafael J. Wysocki2009-12-311-1/+1
| | | | | | | | | | | | | After commit b9c3b266411d27f1a6466c19d146d08db576bfea ("PCI: support device-specific reset methods") the kernel build is broken if CONFIG_PCI_QUIRKS is unset. Fix this by moving pci_dev_specific_reset() to drivers/pci/quirks.c and providing an empty replacement for !CONFIG_PCI_QUIRKS builds. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PCI: support device-specific reset methodsDexuan Cui2009-12-161-0/+8
| | | | | | | | | | Add a new type of quirk for resetting devices at pci_dev_reset time. This is necessary to handle device with nonstandard reset procedures, especially useful for guest drivers. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: acs p2p upsteram forwarding enablingAllen Kay2009-11-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Note: dom0 checking in v4 has been separated out into 2/2. This patch enables P2P upstream forwarding in ACS capable PCIe switches. It solves two potential problems in virtualization environment where a PCIe device is assigned to a guest domain using a HW iommu such as VT-d: 1) Unintentional failure caused by guest physical address programmed into the device's DMA that happens to match the memory address range of other downstream ports in the same PCIe switch. This causes the PCI transaction to go to the matching downstream port instead of go to the root complex to get translated by VT-d as it should be. 2) Malicious guest software intentionally attacks another downstream PCIe device by programming the DMA address into the assigned device that matches memory address range of the downstream PCIe port. We are in process of implementing device filtering software in KVM/XEN management software to allow device assignment of PCIe devices behind a PCIe switch only if it has ACS capability and with the P2P upstream forwarding bits enabled. This patch is intended to work for both KVM and Xen environments. Signed-off-by: Allen Kay <allen.m.kay@intel.com> Reviewed-by: Mathew Wilcox <willy@linux.intel.com> Reviewed-by: Chris Wright <chris@sous-sol.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Simplify hotplug mch quirk.Eric W. Biederman2009-09-091-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | There is a very old quirk for the intel E7502 E7320 and E7525 memory controller hubs that disables usage of msi interrupts on pcie hotplug bridges of those devices, and disables changing the affinity of irqs. Today all we have to do to disable msi on a specific device is to set dev->no_msi, which is much more straightforward than the previous logic. The re-running of this fixup after pci hotplug happens below these devices is totally bogus. All of the state we change is pure software state and we don't change the hardware at all. Which means hotplug on the lower devices doesn't have a chance to change this state. So we can safely remove the special case from the pciehp driver and the pcie portdriver. I suspect the special case was someone's expermental debug code that slipped in. Certainly it isn't mentioned in commit 6fb8880a61510295aece04a542767161f624dffe aka BKrev: 41966101LJ_ogfOU0m2aE6teZfQnuQ where the code first appears. Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: expose function reset capability in sysfsMichael S. Tsirkin2009-09-091-0/+1
| | | | | | | | | | | | | | Some devices allow an individual function to be reset without affecting other functions in the same device: that's what pci_reset_function does. For devices that have this support, expose reset attribite in sysfs. This is useful e.g. for virtualization, where a qemu userspace process wants to reset the device when the guest is reset, to emulate machine reboot as closely as possible. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI SR-IOV: correct broken resource alignment calculationsChris Wright2009-08-301-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An SR-IOV capable device includes an SR-IOV PCIe capability which describes the Virtual Function (VF) BAR requirements. A typical SR-IOV device can support multiple VFs whose BARs must be in a contiguous region, effectively an array of VF BARs. The BAR reports the size requirement for a single VF. We calculate the full range needed by simply multiplying the VF BAR size with the number of possible VFs and create a resource spanning the full range. This all seems sane enough except it artificially inflates the alignment requirement for the VF BAR. The VF BAR need only be aligned to the size of a single BAR not the contiguous range of VF BARs. This can cause us to fail to allocate resources for the BAR despite the fact that we actually have enough space. This patch adds a thin PCI specific layer over the generic resource_alignment() function which is aware of the special nature of VF BARs and does sorting and allocation based on the smaller alignment requirement. I recognize that while resource_alignment is generic, it's basically a PCI helper. An alternative to this patch is to add PCI VF BAR specific information to struct resource. I opted for the extra layer rather than adding such PCI specific information to struct resource. This does have the slight downside that we don't cache the BAR size and re-read for each alignment query (happens a small handful of times during boot for each VF BAR). Signed-off-by: Chris Wright <chrisw@sous-sol.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Yu Zhao <yu.zhao@intel.com> Cc: stable@kernel.org Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: handle Virtual Function ATS enablingYu Zhao2009-05-181-1/+3
| | | | | | | | | | | The SR-IOV spec requires that the Smallest Translation Unit and the Invalidate Queue Depth fields in the Virtual Function ATS capability are hardwired to 0. If a function is a Virtual Function, then and set its Physical Function's STU before enabling the ATS. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* PCI: support the ATS capabilityYu Zhao2009-05-181-0/+37
| | | | | | | | | | | The PCIe ATS capability makes the Endpoint be able to request the DMA address translation from the IOMMU and cache the translation in the device side, thus alleviate IOMMU pressure and improve the hardware performance in the I/O virtualization environment. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* Merge branch 'linux-next' of ↵Linus Torvalds2009-04-011-0/+65
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (88 commits) PCI: fix HT MSI mapping fix PCI: don't enable too much HT MSI mapping x86/PCI: make pci=lastbus=255 work when acpi is on PCI: save and restore PCIe 2.0 registers PCI: update fakephp for bus_id removal PCI: fix kernel oops on bridge removal PCI: fix conflict between SR-IOV and config space sizing powerpc/PCI: include pci.h in powerpc MSI implementation PCI Hotplug: schedule fakephp for feature removal PCI Hotplug: rename legacy_fakephp to fakephp PCI Hotplug: restore fakephp interface with complete reimplementation PCI: Introduce /sys/bus/pci/devices/.../rescan PCI: Introduce /sys/bus/pci/devices/.../remove PCI: Introduce /sys/bus/pci/rescan PCI: Introduce pci_rescan_bus() PCI: do not enable bridges more than once PCI: do not initialize bridges more than once PCI: always scan child buses PCI: pci_scan_slot() returns newly found devices PCI: don't scan existing devices ... Fix trivial append-only conflict in Documentation/feature-removal-schedule.txt
| * PCI: Introduce /sys/bus/pci/rescanAlex Chiang2009-03-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This interface allows the user to force a rescan of all PCI buses in system, and rediscover devices that have been removed earlier. pci_bus_attrs implementation from Trent Piepho. Thanks to Vegard Nossum for discovering locking issues with the sysfs interface. Cc: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: handle SR-IOV Virtual Function MigrationYu Zhao2009-03-201-0/+4
| | | | | | | | | | | | | | | | | | Add or remove a Virtual Function after receiving a Migrate In or Out Request. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: add SR-IOV API for Physical Function driverYu Zhao2009-03-201-0/+2
| | | | | | | | | | | | | | | | | | | | Add or remove the Virtual Function when the SR-IOV is enabled or disabled by the device driver. This can happen anytime rather than only at the device probe stage. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: centralize device setup codeYu Zhao2009-03-201-0/+1
| | | | | | | | | | | | | | | | | | Move the device setup stuff into pci_setup_device() which will be used to setup the Virtual Function later. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: reserve bus range for SR-IOV deviceYu Zhao2009-03-201-0/+5
| | | | | | | | | | | | | | | | | | Reserve the bus number range used by the Virtual Function when pcibios_assign_all_busses() returns true. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: restore saved SR-IOV stateYu Zhao2009-03-201-0/+4
| | | | | | | | | | | | | | | | | | Restore the volatile registers in the SR-IOV capability after the D3->D0 transition. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: initialize and release SR-IOV capabilityYu Zhao2009-03-201-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | If a device has the SR-IOV capability, initialize it (set the ARI Capable Hierarchy in the lowest numbered PF if necessary; calculate the System Page Size for the VF MMIO, probe the VF Offset, Stride and BARs). A lock for the VF bus allocation is also initialized if a PF is the lowest numbered PF. Reviewed-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * PCI: allow assignment of memory resources with a specified alignmentYuji Shimada2009-03-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows memory resources to be assigned with a specified alignment at boot-time or run-time. The patch is useful when we use PCI pass-through, because page-aligned memory resources are required to securely share PCI resources with guest drivers. If you want to assign the resource at boot time, please set "pci=resource_alignment=" boot parameter. This is format of "pci=resource_alignment=" boot parameter: [<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...] Specifies alignment and device to reassign aligned memory resources. If <order of align> is not specified, PAGE_SIZE is used as alignment. PCI-PCI bridge can be specified, if resource windows need to be expanded. This is example: pci=resource_alignment=20@07:00.0;18@0f:00.0;00:1d.7 If you want to assign the resource at run-time, please set "/sys/bus/pci/resource_alignment" file, and hot-remove the device and hot-add the device. For this purpose, fakephp or PCI hotplug interfaces can be used. The format of "/sys/bus/pci/resource_alignment" file is the same with boot parameter. You can use "," instead of ";". For example: # cd /sys/bus/pci # echo -n 20@12:00.0 > resource_alignment # echo 1 > devices/0000:12:00.0/remove # echo 1 > rescan Reviewed-by: Alex Chiang <achiang@hp.com> Reviewed-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | PCI PM: Move pci_restore_standard_config to pci-driver.cRafael J. Wysocki2009-03-301-1/+0
|/ | | | | | | | | Move pci_restore_standard_config() from pci.c to pci-driver.c and make it static. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: fix struct pci_platform_pm_ops kernel-docRandy Dunlap2009-02-131-10/+10
| | | | | | | Fix struct pci_platform_pm_ops kernel-doc notation. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI PM: Restore standard config registers of all devices earlyRafael J. Wysocki2009-01-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | There is a problem in our handling of suspend-resume of PCI devices that many of them have their standard config registers restored with interrupts enabled and they are put into the full power state with interrupts enabled as well. This may lead to the following scenario: * an interrupt vector is shared between two or more devices * one device is resumed earlier and generates an interrupt * the interrupt handler of another device tries to handle it and attempts to access the device the config space of which hasn't been restored yet and/or which still is in a low power state * the system crashes as a result To prevent this from happening we should restore the standard configuration registers of all devices with interrupts disabled and we should put them into the D0 power state right after that. Unfortunately, this cannot be done using the existing pci_set_power_state(), because it can sleep. Also, to do it we have to make sure that the config spaces of all devices were actually saved during suspend. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI PM: Avoid touching devices behind bridges in unknown stateRafael J. Wysocki2009-01-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | It generally is better to avoid accessing devices behind bridges that may not be in the D0 power state, because in that case the bridges' secondary buses may not be accessible. For this reason, during the early phase of resume (ie. with interrupts disabled), before restoring the standard config registers of a device, check the power state of the bridge the device is behind and postpone the restoration of the device's config space, as well as any other operations that would involve accessing the device, if that state is not D0. In such cases the restoration of the device's config space will be retried during the "normal" phase of resume (ie. with interrupts enabled), so that the bridge can be put into D0 before that happens. Also, save standard configuration registers of PCI devices during the "normal" phase of suspend (ie. with interrupts enabled), so that the bridges the devices are behind can be put into low power states (we don't put bridges into low power states at the moment, but we may want to do it in the future and it seems reasonable to design for that). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI PM: Add suspend counterpart of pci_reenable_deviceRafael J. Wysocki2009-01-071-0/+1
| | | | | | | | | | | | | | | | | PCI devices without drivers are not disabled during suspend and hibernation, but they are enabled during resume, with the help of pci_reenable_device(), so there is an unbalanced execution of pcibios_enable_device() in the resume code path. To correct this introduce function pci_disable_enabled_device() that will disable the argument device, if it is enabled when the function is being run, without updating the device's pci_dev structure and use it in the suspend code path to balance the pci_reenable_device() executed during resume. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: revise VPD access interfaceStephen Hemminger2009-01-071-3/+3
| | | | | | | | | | | Change PCI VPD API which was only used by sysfs to something usable in drivers. * move iteration over multiple words to the low level * use conventional types for arguments * add exportable wrapper Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: set device wakeup capable flag if platform support is presentJesse Barnes2009-01-071-0/+1
| | | | | | | | | | | | | When PCI devices are initialized, we check whether they support PCI PM caps and set the device can_wakeup flag if so. However, some devices may have platform provided wakeup events rather than PCI PME signals, so we need to set can_wakeup in that case too. Doing so should allow wakeups from many more devices, especially on cost constrained systems. Reported-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Joseph Chan <JosephChan@via.com.tw> Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: factor pci_bus_add_child() from pci_bus_add_devices()Yu Zhao2009-01-071-0/+1
| | | | | | | | | This patch splits a new function, pci_bus_add_child(), from pci_bus_add_devices(). The new function can be used to register PCI buses to the device core. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: add a new function to map BAR offsetsYu Zhao2009-01-071-0/+2
| | | | | | | | Add a function to map a given resource number to a corresponding register so drivers can get the offset and type of device specific BARs. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: export __pci_read_base()Yu Zhao2009-01-071-0/+9
| | | | | | | Export __pci_read_base() so it can be used by whole PCI subsystem. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: enhance pci_ari_enabled()Yu Zhao2009-01-071-3/+3
| | | | | | | | | | | Change parameter of pci_ari_enabled() from 'pci_dev' to 'pci_bus'. ARI forwarding on the bridge mostly concerns the subordinate devices rather than the bridge itself. So this change will make the function easier to use. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: handle PCI state saving with interrupts disabledRafael J. Wysocki2009-01-071-0/+1
| | | | | | | | | | Since interrupts will soon be disabled at PCI resume time, we need to pre-allocate memory to save/restore PCI config space (or use GFP_ATOMIC, but this is safer). Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: PCI MSI _OSC support capabilities called when root bridge addedAndrew Patterson2009-01-071-2/+0
| | | | | | | | | | The _OSC capability OSC_MSI_SUPPORT is set when the root bridge is added with pci_acpi_osc_support(), so we no longer need to do it in the PCI MSI driver. Also adds the function pci_msi_enabled, which returns true if pci=nomsi is not on the kernel command-line. Signed-off-by: Andrew Patterson <andrew.patterson@hp.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: check mmap range of /proc/bus/pci files tooJesse Barnes2009-01-071-0/+4
| | | | | | | | /proc/bus/pci allows you to mmap resource ranges too, so we should probably be checking to make sure the mapping is somewhat valid. Uses the same code as the recent sysfs mmap range checking patch from Linus. Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* ACPI/PCI: Set support bit for MSI in support field of _OSCTaku Izumi2008-10-221-0/+2
| | | | | | | | | Currently linux doesn't have any code to set the "MSI supported" bit in Support Fireld of _OSC. This patch adds the code for that. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: Add ability to mmap legacy_io on some platformsBenjamin Herrenschmidt2008-10-201-0/+6
| | | | | | | | | | | | | | This adds the ability to mmap legacy IO space to the legacy_io files in sysfs on platforms that support it. This will allow to clean up X to use this instead of /dev/mem for legacy IO accesses such as those performed by Int10. While at it I moved pci_create/remove_legacy_files() to pci-sysfs.c where I think they belong, thus making more things statis in there and cleaned up some spurrious prototypes in the ia64 pci.h file Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* PCI: support PCIe ARI capabilityYu Zhao2008-10-201-0/+12
| | | | | | | | | | | | This patch adds support for PCI Express Alternative Routing-ID Interpretation (ARI) capability. The ARI capability extends the Function Number field of the PCI Express Endpoint by reusing the Device Number which is otherwise hardwired to 0. With ARI, an Endpoint can have up to 256 functions. Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
OpenPOWER on IntegriCloud