summaryrefslogtreecommitdiffstats
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2014-02-19PCI: Remove unused SR-IOV VF Migration supportBjorn Helgaas2-123/+0
This reverts commit 74bb1bcc7dbb ("PCI: handle SR-IOV Virtual Function Migration"), removing this exported interface: pci_sriov_migration() Since pci_sriov_migration() is unused, it is impossible to schedule sriov_migration_task() or use any of the other migration infrastructure. This is based on Stephen Hemminger's patch (see link below), but goes a bit further. Link: http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplumber.net Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Stephen Hemminger <stephen@networkplumber.org>
2014-02-18Merge branch 'pci/misc' into nextBjorn Helgaas3-37/+39
* pci/misc: PCI: Enable INTx if BIOS left them disabled ia64/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device x86/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device PCI: Update outdated comment for pcibios_bus_report_status() PCI: Cleanup per-arch list of object files PCI: cpqphp: Fix hex vs decimal typo in cpqhpc_probe() x86/PCI: Fix function definition whitespace x86/PCI: Reword comments x86/PCI: Remove unnecessary local variable initialization PCI: Remove unnecessary list_empty(&pci_pme_list) check
2014-02-18PCI: Enable INTx if BIOS left them disabledBjorn Helgaas1-0/+10
Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng <chris.cheng@atrustcorp.com> Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2014-02-18Merge branch 'pci/host-mvebu' into nextBjorn Helgaas1-11/+26
* pci/host-mvebu: PCI: mvebu: Call request_resource() on the apertures bus: mvebu-mbus: Fix incorrect size for PCI aperture resources PCI: mvebu: Fix potential issue in range parsing PCI: mvebu: Use Device ID and revision from underlying endpoint
2014-02-18Merge branch 'pci/list-for-each-entry' into nextBjorn Helgaas3-11/+11
* pci/list-for-each-entry: PCI: Remove pci_bus_b() and use list_for_each_entry() directly pcmcia: Use list_for_each_entry() for bus traversal powerpc/PCI: Use list_for_each_entry() for bus traversal drm: Use list_for_each_entry() for bus traversal ARM/PCI: Use list_for_each_entry() for bus traversal ACPI / hotplug / PCI: Use list_for_each_entry() for bus traversal
2014-02-18PCI: mvebu: Call request_resource() on the aperturesJason Gunthorpe1-1/+23
It is typical for host drivers to request a resource for the aperture; once this is done the PCI core will properly populate resources for all BARs in the system. With this patch cat /proc/iomem will now show: e0000000-efffffff : PCI MEM 0000 e0000000-e00fffff : PCI Bus 0000:01 e0000000-e001ffff : 0000:01:00.0 Tested on Kirkwood. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net>
2014-02-18PCI: rcar: Break out window size handlingMagnus Damm1-3/+28
Break out the hard coded window size code to allow dynamic setup. The window size is still left at 1GiB but with this patch changing window size is easy for testing. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-18PCI: rcar: Register each instance independentlyMagnus Damm1-60/+20
Convert the code to allow per-device probe() like other device drivers. This also delays driver registration due to change from subsys_initcall() to regular module_platform_driver(). Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-18PCI: rcar: Fix bridge logic configuration accessesBen Dooks1-0/+4
The bridge logic at slot 0 only supports reads up to 0x40 and the rest of the PCI configuration space for this slot is marked as reserved in the manual. Trying a read from offset 0x100 is producing an error from the bridge. With error interrupts enabled, the following is printed: pci-rcar-gen2 ee0d0000.pci: error irq: status 00000014 Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-18PCI: rcar: Add error interrupt handlingBen Dooks1-0/+60
Add option to enable interrupts to report any errors from the AHB-PCI bridge to help find any issues with the bridge when in use. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-18PCI: rcar: Check platform_get_irq() return codeBen Dooks1-0/+5
The current code does not check the return from platform_get_irq() so add an error check and return if this call does fail. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
2014-02-18Merge 3.14-rc3 into driver-core-nextGreg Kroah-Hartman1-2/+13
We want those fixes here for testing and development. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-16ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHPRafael J. Wysocki1-5/+8
Currently, ACPIPHP does not add hotplug context to devices that should be handled by the native PCI hotplug (PCIeHP) code. The reason why was because PCIeHP didn't know about the devices' connections with ACPI and would not clean up things properly during an eject of an ACPI-backed device, for example. However, after recent changes that made the ACPI core create struct acpi_device objects for all namespace nodes regardless of the underlying devices' status and added PCI rescan-remove locking to both ACPIPHP and PCIeHP, that concern is not valid any more. Namely, after those changes PCIeHP need not care about the ACPI side of things any more and it should be serialized with respect to ACPIPHP and they won't be running concurrently with each other in any case. For this reason, make ACPIPHP to add its hotplug context to all devices with ACPI companions, even the ones that should be handled by PCIeHP in principle. That may work around hotplug issues on some systems where PCIeHP is supposed to work, but it doesn't and the ACPI hotplug signaling works instead. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16ACPI / hotplug / PCI: Rename register_slot() to acpiphp_add_context()Rafael J. Wysocki1-5/+11
The name of register_slot() doesn't really reflect what the function is does, so rename it to acpiphp_add_context() and add a proper kerneldoc comment to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-14Merge branch 'pci/msi' into nextBjorn Helgaas1-2/+8
* pci/msi: vfio: Use pci_enable_msi_range() and pci_enable_msix_range() ahci: Use pci_enable_msi_range() instead of pci_enable_msi_block() ahci: Fix broken fallback to single MSI mode PCI/MSI: Add pci_enable_msi_exact() and pci_enable_msix_exact() PCI/MSI: Fix cut-and-paste errors in documentation PCI/MSI: Add pci_enable_msi() documentation back PCI/MSI: Fix pci_msix_vec_count() htmldocs failure PCI/MSI: Fix leak of msi_attrs PCI/MSI: Check kmalloc() return value, fix leak of name
2014-02-14Merge branch 'pci/virtualization' into nextBjorn Helgaas2-6/+205
* pci/virtualization: PCI: Enable quirks for PCIe ACS on Intel PCH root ports PCI: Add pci_dev_flag for ACS enable quirks PCI: Add device-specific PCI ACS enable
2014-02-14PCI: Enable INTx if BIOS left them disabledBjorn Helgaas1-0/+10
Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng <chris.cheng@atrustcorp.com> Reported-and-tested-by: Jamie Chen <jamie.chen@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2014-02-14PCI: Remove pci_bus_b() and use list_for_each_entry() directlyYijing Wang2-8/+8
Replace list_for_each() with list_for_each_entry(), which means we no longer need pci_bus_b() and can remove it. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-14PCI: mvebu: Fix potential issue in range parsingJean-Jacques Hiblot1-1/+1
The second parameter of of_read_number() is not the index, but a size. As it happens, in this case it may work just fine because of the conversion to u32 and the favorable endianness on this architecture. Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout") Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Cc: stable@vger.kernel.org # v3.12+
2014-02-14ACPI / hotplug / PCI: Use list_for_each_entry() for bus traversalYijing Wang1-3/+3
Replace list_for_each() + pci_bus_b() with list_for_each_entry(). Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
2014-02-14PCI: pciehp: Don't turn slot off when hot-added device already existsYijing Wang2-2/+3
If we found device already exists during hot add device, we should leave it, not turn the slot off. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-13PCI/MSI: Fix pci_msix_vec_count() htmldocs failureMasanari Iida1-1/+0
An empty line in msi.c caused "make htmldocs" failure: Warning(/home/iida/Repo/linux-next//drivers/pci/msi.c:962): bad line: Fixes: ff1aa430a2fa ("PCI/MSI: Add pci_msix_vec_count()") Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-13PCI/MSI: Fix leak of msi_attrsGreg Kroah-Hartman1-0/+1
Coverity reported that I forgot to clean up some allocated memory on the error path in populate_msi_sysfs(), so this patch fixes that. Thanks to Dave Jones for pointing out where the error was, I obviously can't read code this morning... Found by Coverity (CID 1163317). Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Dave Jones <davej@redhat.com>
2014-02-13PCI/MSI: Check kmalloc() return value, fix leak of nameGreg Kroah-Hartman1-1/+7
Coverity reported that I forgot to check the return value of kmalloc() when creating the MSI attribute name, so fix that up and properly free it if there is an error when allocating the msi_dev_attr variable. Found by Coverity (CID 1163315 and 1163316). Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-12PCI: Cleanup per-arch list of object filesLiviu Dudau1-14/+8
setup-bus.o is now included unconditionally as of commit 7dc303033425 ("PCI: Always build setup-bus when PCI is enabled"). Remove it from the per-arch list of object files. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-12PCI: cpqphp: Fix hex vs decimal typo in cpqhpc_probe()Dan Carpenter1-2/+2
This is a static checker fix and I can't test it, but from the context it definitely looks like hexadecimal 0x20 was intended here instead of decimal 20. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-12PCI: mvebu: Use Device ID and revision from underlying endpointAndrew Lunn1-9/+2
Marvell SoCs place the SoC number into the PCIe endpoint device ID. The SoC stepping is placed into the PCIe revision. The old plat-orion PCIe driver allowed this information to be seen in user space with a simple lspci command. The new driver places a virtual PCI-PCI bridge on top of these endpoints. It has its own hard coded PCI device ID. Thus it is no longer possible to see what the SoC is using lspci. When initializing the PCI-PCI bridge, set its device ID and revision from the underlying endpoint, thus restoring this functionality. Debian would like to use this in order to aid installing the correct DTB file. Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Cc: stable@vger.kernel.org # v3.11+
2014-02-12PCI: mvebu: Use Device ID and revision from underlying endpointAndrew Lunn1-9/+2
Marvell SoCs place the SoC number into the PCIe endpoint device ID. The SoC stepping is placed into the PCIe revision. The old plat-orion PCIe driver allowed this information to be seen in user space with a simple lspci command. The new driver places a virtual PCI-PCI bridge on top of these endpoints. It has its own hard coded PCI device ID. Thus it is no longer possible to see what the SoC is using lspci. When initializing the PCI-PCI bridge, set its device ID and revision from the underlying endpoint, thus restoring this functionality. Debian would like to use this in order to aid installing the correct DTB file. Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Cc: stable@vger.kernel.org # v3.11+
2014-02-12Merge back earlier 'acpi-pci-hotplug' material.Rafael J. Wysocki2-285/+136
Conflicts: drivers/pci/hotplug/acpiphp_glue.c
2014-02-12ACPI / hotplug / PCI: Relax the checking of _STA return valuesMika Westerberg1-2/+13
The ACPI specification (ACPI 5.0A, Section 6.3.7) says: _STA may return bit 0 clear (not present) with bit 3 set (device is functional). This case is used to indicate a valid device for which no device driver should be loaded (for example, a bridge device.) Children of this device may be present and valid. OSPM should continue enumeration below a device whose _STA returns this bit combination. Evidently, some BIOSes follow that and return 0x0A from _STA, which causes problems to happen when they trigger bus check or device check notifications for those devices too. Namely, ACPIPHP thinks that they are gone and may drop them, for example, if such a notification is triggered during a resume from system suspend. To fix that, modify ACPICA to regard devies as present and functioning if _STA returns both the ACPI_STA_DEVICE_ENABLED and ACPI_STA_DEVICE_FUNCTIONING bits set for them. Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com> Cc: 3.12+ <stable@vger.kernel.org> # 3.12+ [rjw: Subject and changelog, minor code modifications] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11PCI: pciehp: Add hotplug_lock to serialize hotplug eventsRajat Jain4-3/+23
Today it is there is no protection around pciehp_enable_slot() and pciehp_disable_slot() to ensure that they complete before another hot-plug operation can be done on that particular slot. This patch introduces the slot->hotplug_lock to ensure that any hotplug operations (add / remove) complete before another hotplug event can begin processing on that particular slot. Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: pciehp: Ensure very fast hotplug events are also processedRajat Jain1-9/+20
Today, this is how all the hotplug and unplug events work: Hotplug / Removal needs to be done => Set slot->state (protected by slot->lock) to either POWERON_STATE (for enabling) or POWEROFF_STATE (for disabling). => Submit the work item for pciehp_power_thread() to slot->wq. Problem: There is a problem if the hotplug events can happen fast enough that they do not give SW enough time to add or remove the new devices. => Assume: Event for unplug comes (e.g. surprise removal). But before the pciehp_power_thread() work item was executed, the card was replaced by another card, causing surprise hotplug event. => What goes wrong: => The hot-removal event sets slot->state to POWEROFF_STATE, and schedules the pciehp_power_thread(). => The hot-add event sets slot->state to POWERON_STATE, and schedules the pciehp_power_thread(). => Now the pciehp_power_thread() is scheduled twice, and on both occasions it will find POWERON_STATE and will try to add the devices on the slot, and will fail complaining that the devices already exist. => Why this is a problem: If the device was replaced between the hot removal and hot-add, then we should unload the old driver and reload the new one. This does not happen today. The kernel or the driver is not even aware that the device was replaced. The problem is that the pciehp_power_thread() only looks at the slot->state which would only contain the *latest* state - not the actual event (add / remove) that was the intent of the IRQ handler who submitted the work. What this patch does: => Hotplug events pass on an actual request (for addition or removal) to pciehp_power_thread() which is local to that work item submission. => pciehp_power_thread() does not need to look at slote->state and hence no locks needed in that. => Essentially this results in all the hotplug and unplug events "replayed" by pciehp_power_thread(). Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: pciehp: Disable link notification across slot resetRajat Jain1-13/+17
Disable the link notification (in addition to presence detect notifications) across the slot reset since the reset could flap the link, and we don't want to treat it as hot unplug followed by a hotplug. Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: pciehp: Don't check adapter or latch status while disablingRajat Jain1-18/+0
It does not make much sense to refuse to disable a slot if an adapter is not present or the latch is open. If an adapter is not present, it provides an even better reason to disable the device slot. This is specially a problem for link state hot-plug, because some ports use in band mechanism for presence detection. Thus when link goes down, presence detect also goes down. We _want_ that the removal should take place in such case. Thus remove the checks for adapter and latch in pciehp_disable_slot() Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: pciehp: Don't disable the link permanently during removalRajat Jain1-18/+0
We need future link up events for hot-add, thus don't disable the link permanently during device removal. Also, remove the static functions that are now left unused. This reverts part of 2debd9289997 ("PCI: pciehp: Disable/enable link during slot power off/on"). This was discussed at the URL below, where it was revealed that it was done for a bug in a PCIe repeater chip on that particular platform. Link: https://lkml.kernel.org/r/CAErSpo72KZ-a2OSQLWoK71GCgwBt676XZdGt4tEYm-6UYnLmPw@mail.gmail.com Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: pciehp: Enable link state change notificationsRajat Jain1-2/+11
Enable the Link state notifications unconditionally. Enable the presence detection notification only if attention button is absent. This was discussed at this thread: https://lkml.kernel.org/r/529E5C0E.80903@gmail.com Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Don't scan random busses in pci_scan_bridge()Andreas Noever1-3/+7
When assigning a new bus number in pci_scan_bridge we check whether max+1 is free by calling pci_find_bus. If it does already exist then we assume that we are rescanning and that this is the right bus to scan. This is fragile. If max+1 lies outside of bus->busn_res.end then we will rescan some random bus from somewhere else in the hierachy. This patch checks for this case and prints a warning. [bhelgaas: add parent/child bus number info to dev_warn()] Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Check for child busses which use more bus numbers than allocatedAndreas Noever1-4/+6
pci_scan_child_bus can (potentially) return a bus number higher than the subordinate value of the child bus. Possible reasons are that bus numbers are reserved for SR-IOV or for CardBus (SR-IOV is done without checks and the CardBus checks are sketchy at best). We clamp the returned value to the actual subordinate value and print a warning if too many bus numbers are reserved. [bhelgaas: whitespace] Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Remove pci_fixup_parent_subordinate_busnr()Andreas Noever1-30/+0
The function has no effect. If pcibios_assign_all_busses() is not set then the function does nothing. If it is set then in pci_scan_bridge we are always in the branch where we assign the bus numbers ourselves and the subordinate values of all parent busses will be set to 0xff since that is what they inherited from their parent bus and ultimately from the root bus. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Enable quirks for PCIe ACS on Intel PCH root portsAlex Williamson1-0/+160
Many of the currently available Intel PCH-based root ports do not provide PCIe ACS capabilities. Without this, we must assume that peer-to-peer traffic between multifunction root ports and between devices behind root ports is possible. This lack of isolation is exposed by grouping the devices together in the same IOMMU group. If we want to expose these devices to userspace, vfio uses IOMMU groups as the unit of ownership, thus making it very difficult to assign individual devices to separate users. The good news is that the chipset does provide ACS-like isolation capabilities, but we do need to verify and enable those capabilities if the BIOS has not done so. This patch implements the device specific enabling and testing of equivalent ACS function for these devices. 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>
2014-02-11PCI: Add device-specific PCI ACS enableAlex Williamson2-6/+45
Some devices support PCI ACS-like features, but don't report it using the standard PCIe capabilities. We already provide hooks for device-specific testing of ACS, but not for device-specific enabling of ACS. This provides that setup hook. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: pciehp: Use link change notifications for hot-plug and removalRajat Jain3-1/+96
A lot of systems do not have the fancy buttons and LEDs, and instead want to rely only on the Link state change events to drive the hotplug and removal state machinery. (http://www.spinics.net/lists/hotplug/msg05802.html) This patch adds support for that functionality. Here are the details about the patch itself: * Define and use interrupt events for linkup / linkdown. * Make the pcie_isr() also look at link events, and direct control to corresponding (new) link state change handler function. * Introduce the functions to handle link-up and link-down events and queue the add / removal work in the slot->wq to be processed by pciehp_power_thread() As a side note, this patch also fixes the bug https://bugzilla.kernel.org/show_bug.cgi?id=65521 "pciehp ignores Data Link Layer State Changed bit." Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: pciehp: Make check_link_active() non-staticRajat Jain2-3/+4
check_link_active() functionality needs to be used by subsequent patches (that introduce link state change based hotplug). Thus make the function non-static, and rename it to pciehp_check_link_active() so as to be consistent with other non-static functions. Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10Merge branch 'master' into driver-core-next-test-merge-rc2Tejun Heo1-11/+44
da9846ae1518 ("kernfs: make kernfs_deactivate() honor KERNFS_LOCKDEP flag") in driver-core-linus conflicts with kernfs_drain() updates in driver-core-next. The former just adds the missing KERNFS_LOCKDEP checks which are already handled by kernfs_lockdep() checks in driver-core-next. The conflict can be resolved by taking code from driver-core-next. Conflicts: fs/kernfs/dir.c
2014-02-10PCI: Make sure bus number resources stay within their parents boundsAndreas Noever1-2/+8
Right now we use 0xff for busn_res.end when probing and later reduce it to the value that is actually used. This does not work if a parent bridge has already a lower subordinate value. For example during hotplug of a new bridge below an already-configured bridge the following message is printed from pci_bus_insert_busn_res(): pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-9b] (conflicts with (null) [bus 05-9b]) This patch clamps the bus range to that of the parent and also ensures that we do not exceed the parents range when assigning the final subordinate value. We also check that busses configured by the firmware fit into their parents bounds. [bhelgaas: reword dev_warn() and fix printk format warning] Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Use request_resource_conflict() instead of insert_ for bus numbersAndreas Noever1-1/+1
If a conflict happens during insert_resource_conflict() and all conflicts fit within the newly inserted resource then they will become children of the new resource. This is almost certainly not what we want for bus numbers. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Assign CardBus bus number only during the second passAndreas Noever1-1/+1
Right now the CardBus code in pci_scan_bridge() is executed during both passes. Since we always allocate the bus number ourselves it makes sense to put it into the second pass. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Clarify the "scan anyway" comment in pci_scan_bridge()Andreas Noever1-5/+4
Initially when we encountered a bus that was already present we skipped it. Since 74710ded8e16 'PCI: always scan child buses' we continue scanning in order to allow user triggered rescans of already existing busses. The old comment suggested that the reason for continuing the scan is a bug in the i450NX chipset. This is not the case. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Increment max correctly in pci_scan_bridge()Andreas Noever1-2/+3
This patch fixes two small issues: - If pci_add_new_bus() fails, max must not be incremented. Otherwise an incorrect value is returned from pci_scan_bridge(). - If the bus is already present, max must be incremented. I think that this case should only be hit if we trigger a manual rescan of a CardBus bridge. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10ACPI / hotplug / PCI: Execute _EJ0 under the ACPI scan lockRafael J. Wysocki1-0/+6
Since acpi_device_hotplug() assumes that ACPI handles of device objects passed to it will not become invalid while acpi_scan_lock is being held, make acpiphp_disable_slot() acquire acpi_scan_lock, because it generally causes _EJ0 to be executed for one of the devices in the slot and that may cause its ACPI handle to become invalid. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-26 08:13:49 +0000