aboutsummaryrefslogtreecommitdiff
path: root/drivers/pci/hotplug
AgeCommit message (Collapse)Author
2013-06-24ACPI / dock / PCI: Synchronous handling of dock events for PCI devicesRafael J. Wysocki
The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic because of ordering issues during hot-remove operations. First of all, the current ACPI glue code expects that physical devices will always be deleted before deleting the companion ACPI device objects. Otherwise, acpi_unbind_one() will fail with a warning message printed to the kernel log, for example: [ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt [ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt [ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt [ 180.013656] port1: Oops, 'acpi_handle' corrupt This means, in particular, that struct pci_dev objects have to be deleted before the struct acpi_device objects they are "glued" with. Now, the following happens the during the undocking of an ACPI-based dock station: 1) hotplug_dock_devices() invokes registered hotplug callbacks to destroy physical devices associated with the ACPI device objects depending on the dock station. It calls dd->ops->handler() for each of those device objects. 2) For PCI devices dd->ops->handler() points to handle_hotplug_event_func() that queues up a separate work item to execute _handle_hotplug_event_func() for the given device and returns immediately. That work item will be executed later. 3) hotplug_dock_devices() calls dock_remove_acpi_device() for each device depending on the dock station. This runs acpi_bus_trim() for each of them, which causes the underlying ACPI device object to be destroyed, but the work items queued up by handle_hotplug_event_func() haven't been started yet. 4) _handle_hotplug_event_func() queued up in step 2) are executed and cause the above failure to happen, because the PCI devices they handle do not have the companion ACPI device objects any more (those objects have been deleted in step 3). The possible breakage doesn't end here, though, because hotplug_dock_devices() may return before at least some of the _handle_hotplug_event_func() work items spawned by it have a chance to complete and then undock() will cause _DCK to be evaluated and that will cause the devices handled by the _handle_hotplug_event_func() to go away possibly while they are being accessed. This means that dd->ops->handler() for PCI devices should not point to handle_hotplug_event_func(). Instead, it should point to a function that will do the work of _handle_hotplug_event_func() synchronously. For this reason, introduce such a function, hotplug_event_func(), and modity acpiphp_dock_ops to point to it as the handler. Unfortunately, however, this is not sufficient, because if the dock code were not changed further, hotplug_event_func() would now deadlock with hotplug_dock_devices() that called it, since it would run unregister_hotplug_dock_device() which in turn would attempt to acquire the dock station's hp_lock mutex already acquired by hotplug_dock_devices(). To resolve that deadlock use the observation that unregister_hotplug_dock_device() won't need to acquire hp_lock if PCI bridges the devices on the dock station depend on are prevented from being removed prematurely while the first loop in hotplug_dock_devices() is in progress. To make that possible, introduce a mechanism by which the callers of register_hotplug_dock_device() can provide "init" and "release" routines that will be executed, respectively, during the addition and removal of the physical device object associated with the given ACPI device handle. Make acpiphp use two new functions, acpiphp_dock_init() and acpiphp_dock_release(), that call get_bridge() and put_bridge(), respectively, on the acpiphp bridge holding the given device, for this purpose. In addition to that, remove the dock station's list of "hotplug devices" and make the dock code always walk the whole list of "dependent devices" instead in such a way that the loops in hotplug_dock_devices() and dock_event() (replacing the loops over "hotplug devices") will take references to the list entries that register_hotplug_dock_device() has been called for. That prevents the "release" routines associated with those entries from being called while the given entry is being processed and for PCI devices this means that their bridges won't be removed (by a concurrent thread) while hotplug_event_func() handling them is being executed. This change is based on two earlier patches from Jiang Liu. References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tracked-down-by: Jiang Liu <jiang.liu@huawei.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org>
2013-06-23PCI / ACPI: Use boot-time resource allocation rules during hotplugJiang Liu
On x86 platforms, the kernel respects PCI resource assignments from the BIOS and only reassigns resources for unassigned BARs at boot time. However, with the ACPI-based hotplug (acpiphp), it ignores the BIOS' PCI resource assignments completely and reassigns all resources by itself. This causes differences in PCI resource allocation between boot time and runtime hotplug to occur, which is generally undesirable and sometimes actively breaks things. Namely, if there are enough resources, reassigning all PCI resources during runtime hotplug should work, but it may fail if the resources are constrained. This may happen, for instance, when some PCI devices with huge MMIO BARs are involved in the runtime hotplug operations, because the current PCI MMIO alignment algorithm may waste huge chunks of MMIO address space in those cases. On the Alexander's Sony VAIO VPCZ23A4R the BIOS allocates limited MMIO resources for the dock station which contains a device (graphics adapter) with a 256MB MMIO BAR. An attempt to reassign that during runtime hotplug causes the dock station MMIO window to be exhausted and acpiphp fails to allocate resources for the majority of devices on the dock station as a result. To prevent that from happening, modify acpiphp to follow the boot time resources allocation behavior so that the BIOS' resource assignments are respected during runtime hotplug too. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=56531 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-17PCI: acpiphp: Re-enumerate devices when host bridge receives Bus CheckYinghai Lu
When a PCI host bridge device receives a Bus Check notification, we must re-enumerate starting with the bridge to discover changes (devices that have been added or removed). Prior to 668192b678 ("PCI: acpiphp: Move host bridge hotplug to pci_root.c"), this happened in _handle_hotplug_event_bridge(). After that commit, _handle_hotplug_event_bridge() is not installed for host bridges, and the host bridge notify handler, _handle_hotplug_event_root() did not re-enumerate. This patch adds re-enumeration to _handle_hotplug_event_root(). This fixes cases where we don't notice the addition or removal of PCI devices, e.g., the PCI-to-USB ExpressCard in the bugzilla below. [bhelgaas: changelog, references] Reference: https://lkml.kernel.org/r/CAAh6nkmbKR3HTqm5ommevsBwhL_u0N8Rk7Wsms_LfP=nBgKNew@mail.gmail.com Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57961 Reported-by: Gavin Guo <tuffkidtt@gmail.com> Tested-by: Gavin Guo <tuffkidtt@gmail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.9+
2013-04-29Merge tag 'pci-v3.10-changes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI updates from Bjorn Helgaas: "PCI changes for the v3.10 merge window: PCI device hotplug - Remove ACPI PCI subdrivers (Jiang Liu, Myron Stowe) - Make acpiphp builtin only, not modular (Jiang Liu) - Add acpiphp mutual exclusion (Jiang Liu) Power management - Skip "PME enabled/disabled" messages when not supported (Rafael Wysocki) - Fix fallback to PCI_D0 (Rafael Wysocki) Miscellaneous - Factor quirk_io_region (Yinghai Lu) - Cache MSI capability offsets & cleanup (Gavin Shan, Bjorn Helgaas) - Clean up EISA resource initialization and logging (Bjorn Helgaas) - Fix prototype warnings (Andy Shevchenko, Bjorn Helgaas) - MIPS: Initialize of_node before scanning bus (Gabor Juhos) - Fix pcibios_get_phb_of_node() declaration "weak" annotation (Gabor Juhos) - Add MSI INTX_DISABLE quirks for AR8161/AR8162/etc (Xiong Huang) - Fix aer_inject return values (Prarit Bhargava) - Remove PME/ACPI dependency (Andrew Murray) - Use shared PCI_BUS_NUM() and PCI_DEVID() (Shuah Khan)" * tag 'pci-v3.10-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (63 commits) vfio-pci: Use cached MSI/MSI-X capabilities vfio-pci: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK PCI: Remove "extern" from function declarations PCI: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK PCI: Drop msi_mask_reg() and remove drivers/pci/msi.h PCI: Use msix_table_size() directly, drop multi_msix_capable() PCI: Drop msix_table_offset_reg() and msix_pba_offset_reg() macros PCI: Drop is_64bit_address() and is_mask_bit_support() macros PCI: Drop msi_data_reg() macro PCI: Drop msi_lower_address_reg() and msi_upper_address_reg() macros PCI: Drop msi_control_reg() macro and use PCI_MSI_FLAGS directly PCI: Use cached MSI/MSI-X offsets from dev, not from msi_desc PCI: Clean up MSI/MSI-X capability #defines PCI: Use cached MSI-X cap while enabling MSI-X PCI: Use cached MSI cap while enabling MSI interrupts PCI: Remove MSI/MSI-X cap check in pci_msi_check_device() PCI: Cache MSI/MSI-X capability offsets in struct pci_dev PCI: Use u8, not int, for PM capability offset [SCSI] megaraid_sas: Use correct #define for MSI-X capability PCI: Remove "extern" from function declarations ...
2013-04-17Merge branch 'pci/cleanup' into nextBjorn Helgaas
* pci/cleanup: PCI: Remove "extern" from function declarations PCI: Warn about failures instead of "must_check" functions PCI: Remove __must_check from definitions PCI: Remove unused variables PCI: Move cpci_hotplug_init() proto to header file PCI: Make local functions/structs static PCI: Fix missing prototype for pcie_port_acpi_setup() Conflicts: drivers/pci/hotplug/acpiphp.h include/linux/pci.h
2013-04-17PCI: Remove "extern" from function declarationsBjorn Helgaas
We had an inconsistent mix of using and omitting the "extern" keyword on function declarations in header files. This removes them all. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-17PCI: Remove __must_check from definitionsBjorn Helgaas
The __must_check (gcc "warn_unused_result") attribute only makes sense when compiling the *caller* of the function, so the attribute should appear on the declaration in the header file, not on the definition. The declarations of these functions are already annotated with __must_check. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-17s390/pci: do not modify function handlesSebastian Ott
Don't modify function handles to get a disabled handle - call clp_disable_fh. With this change we also do no longer deconfigure enabled functions. Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-04-17s390/pci: debug device statesSebastian Ott
Use the debugfs to keep track of a pci function's status changes. Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-04-16Merge branch 'pci/jiang-subdrivers' into nextBjorn Helgaas
* pci/jiang-subdrivers: PCI/ACPI: Remove support of ACPI PCI subdrivers PCI: acpiphp: Protect acpiphp data structures from concurrent updates PCI: acpiphp: Use normal list to simplify implementation PCI: acpiphp: Do not use ACPI PCI subdriver mechanism PCI: acpiphp: Convert acpiphp to be builtin only, not modular PCI/ACPI: Handle PCI slot devices when creating/destroying PCI buses x86/PCI: Implement pcibios_{add|remove}_bus() hooks ia64/PCI: Implement pcibios_{add|remove}_bus() hooks PCI/ACPI: Prepare stub functions to handle ACPI PCI (hotplug) slots PCI: Add pcibios hooks for adding and removing PCI buses PCI: acpiphp: Replace local macros with standard ACPI macros PCI: acpiphp: Remove all functions even if function 0 doesn't exist PCI: acpiphp: Use list_for_each_entry_safe() in acpiphp_sanitize_bus() PCI: Clean up usages of pci_bus->is_added PCI: When removing bus, always remove legacy files & unregister
2013-04-16PCI: acpiphp: Protect acpiphp data structures from concurrent updatesJiang Liu
Now acpiphp_enumerate_slots() and acpiphp_remove_slots() may be invoked concurrently by the PCI core, so add a bridge_mutex and reference count mechanism to protect acpiphp bridge/slot/function data structures. To avoid deadlock, handle_hotplug_event_bridge() will requeue the hotplug event onto the kacpi_hotplug_wq by calling alloc_acpi_hp_work(). But the workaround has introduced a minor race window because the 'bridge' passed to _handle_hotplug_event_bridge() may have already been destroyed when _handle_hotplug_event_bridge() is actually executed by the kacpi_hotplug_wq. So hold a reference count on the passed 'bridge'. Fix the same issue for handle_hotplug_event_func() too. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
2013-04-16PCI: acpiphp: Use normal list to simplify implementationYijing Wang
Use normal list for struct acpiphp_slot to simplify implementation. Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
2013-04-15PCI: Use PCI_EXP_SLTCAP_PSN mask when extracting slot numberBjorn Helgaas
Use PCI_EXP_SLTCAP_PSN mask to make it easier to find where the Physical Slot Number is used. The Physical Slot Number is bits 31:19 of the Slot Capabilities Register, and slot_cap is a u32, so the mask is technically unnecessary, but it's helpful for human readers. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-15PCI: Remove unused variablesBjorn Helgaas
This fixes "set but not used" warnings found via "make W=1". Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-15PCI: Move cpci_hotplug_init() proto to header fileBjorn Helgaas
cpci_hotplug_init() and cpci_hotplug_exit() are defined in cpci_hotplug_core.c but had extern declarations in pci_hotplug_core.c. This puts the declarations in a header file included both places so the compiler can help keep everything consistent. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12PCI: acpiphp: Do not use ACPI PCI subdriver mechanismJiang Liu
Previously the acpiphp driver registered itself as an ACPI PCI subdriver, so its callbacks were invoked when creating/destroying PCI root buses to manage ACPI-based PCI hotplug slots. But it doesn't handle P2P bridge hotplug events, so it will cause strange behaviour if there are hotplug slots associated with a hot-removed P2P bridge. This patch fixes this issue by: 1) Directly hooking into PCI core to update hotplug slot devices when creating/destroying PCI buses through: pci_{add|remove}_bus() -> acpi_pci_{add|remove}_bus() 2) Getting rid of unused ACPI PCI subdriver-related code It also cleans up unused code in the acpiphp driver. [bhelgaas: keep acpi_pci_add_bus() stub for CONFIG_ACPI=n] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
2013-04-12PCI: acpiphp: Convert acpiphp to be builtin only, not modularJiang Liu
Convert acpiphp to be builtin only, with no module option. Previously, when HOTPLUG_PCI_ACPI=m, users could disable acpiphp by removing the module or preventing it from loading. That can't be done if acpiphp is builtin statically, so this adds an "acpiphp.disable" kernel parameter. If a user needs to use this parameter, it is a bug, and we want to hear about it. [bhelgaas: fold in acpiphp.disable here, remove documentation] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-12PCI: acpiphp: Replace local macros with standard ACPI macrosJiang Liu
Replace local defined macros (ACPI_STA_xxx) with standard ACPI macros (ACPI_STA_DEVICE_xxx). Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
2013-04-12PCI: acpiphp: Remove all functions even if function 0 doesn't existJiang Liu
Currently function disable_device() detects slot state by checking existence of PCI function 0. It's unreliable because the PCI device for function 0 may be removed through the sysfs interface. If that happens, it will cause powering off a hotplug slot without destroying all PCI devices. On the other hand, it won't hurt us except wasting some computation power if the check is removed, because all code of disable_device() is self-protected. So remove the check. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
2013-04-12PCI: acpiphp: Use list_for_each_entry_safe() in acpiphp_sanitize_bus()Yijing Wang
Function acpiphp_sanitize_bus() may call pci_stop_and_remove_bus_device(), which in turn may remove device from bus->devices list. So walk the bus->devices list with list_for_each_entry_safe(). Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Toshi Kani <toshi.kani@hp.com>
2013-02-25Merge tag 'pci-v3.9-changes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI changes from Bjorn Helgaas: "Host bridge hotplug - Major overhaul of ACPI host bridge add/start (Rafael Wysocki, Yinghai Lu) - Major overhaul of PCI/ACPI binding (Rafael Wysocki, Yinghai Lu) - Split out ACPI host bridge and ACPI PCI device hotplug (Yinghai Lu) - Stop caching _PRT and make independent of bus numbers (Yinghai Lu) PCI device hotplug - Clean up cpqphp dead code (Sasha Levin) - Disable ARI unless device and upstream bridge support it (Yijing Wang) - Initialize all hot-added devices (not functions 0-7) (Yijing Wang) Power management - Don't touch ASPM if disabled (Joe Lawrence) - Fix ASPM link state management (Myron Stowe) Miscellaneous - Fix PCI_EXP_FLAGS accessor (Alex Williamson) - Disable Bus Master in pci_device_shutdown (Konstantin Khlebnikov) - Document hotplug resource and MPS parameters (Yijing Wang) - Add accessor for PCIe capabilities (Myron Stowe) - Drop pciehp suspend/resume messages (Paul Bolle) - Make pci_slot built-in only (not a module) (Jiang Liu) - Remove unused PCI/ACPI bind ops (Jiang Liu) - Removed used pci_root_bus (Bjorn Helgaas)" * tag 'pci-v3.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (51 commits) PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS ACPI / PCI: Make pci_slot built-in only, not a module PCI/PM: Clear state_saved during suspend PCI: Use atomic_inc_return() rather than atomic_add_return() PCI: Catch attempts to disable already-disabled devices PCI: Disable Bus Master unconditionally in pci_device_shutdown() PCI: acpiphp: Remove dead code for PCI host bridge hotplug PCI: acpiphp: Create companion ACPI devices before creating PCI devices PCI: Remove unused "rc" in virtfn_add_bus() PCI: pciehp: Drop suspend/resume ENTRY messages PCI/ASPM: Don't touch ASPM if forcibly disabled PCI/ASPM: Deallocate upstream link state even if device is not PCIe PCI: Document MPS parameters pci=pcie_bus_safe, pci=pcie_bus_perf, etc PCI: Document hpiosize= and hpmemsize= resource reservation parameters PCI: Use PCI Express Capability accessor PCI: Introduce accessor to retrieve PCIe Capabilities Register PCI: Put pci_dev in device tree as early as possible PCI: Skip attaching driver in device_add() PCI: acpiphp: Keep driver loaded even if no slots found ...
2013-02-21Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 update from Martin Schwidefsky: "The most prominent change in this patch set is the software dirty bit patch for s390. It removes __HAVE_ARCH_PAGE_TEST_AND_CLEAR_DIRTY and the page_test_and_clear_dirty primitive which makes the common memory management code a bit less obscure. Heiko fixed most of the PCI related fallout, more often than not missing GENERIC_HARDIRQS dependencies. Notable is one of the 3270 patches which adds an export to tty_io to be able to resize a tty. The rest is the usual bunch of cleanups and bug fixes." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (42 commits) s390/module: Add missing R_390_NONE relocation type drivers/gpio: add missing GENERIC_HARDIRQ dependency drivers/input: add couple of missing GENERIC_HARDIRQS dependencies s390/cleanup: rename SPP to LPP s390/mm: implement software dirty bits s390/mm: Fix crst upgrade of mmap with MAP_FIXED s390/linker skript: discard exit.data at runtime drivers/media: add missing GENERIC_HARDIRQS dependency s390/bpf,jit: add vlan tag support drivers/net,AT91RM9200: add missing GENERIC_HARDIRQS dependency iucv: fix kernel panic at reboot s390/Kconfig: sort list of arch selected config options phylib: remove !S390 dependeny from Kconfig uio: remove !S390 dependency from Kconfig dasd: fix sysfs cleanup in dasd_generic_remove s390/pci: fix hotplug module init s390/pci: cleanup clp page allocation s390/pci: cleanup clp inline assembly s390/perf: cpum_cf: fallback to software sampling events s390/mm: provide PAGE_SHARED define ...
2013-02-14s390/pci: fix hotplug module initSebastian Ott
Loading the pci hotplug module when no devices are present will fail but unfortunately some hotplug callbacks stay registered to the pci bus level. Fix this by not letting module loading fail when no pci devices are present and provide proper {de}registration functions for these callbacks. Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-02-14s390/pci: rename pci_probe to s390_pci_probeHeiko Carstens
pci_probe is too generic and has a name clash with other common code parts. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-02-13ACPI / hotplug: Fix concurrency issues and memory leaksRafael J. Wysocki
This changeset is aimed at fixing a few different but related problems in the ACPI hotplug infrastructure. First of all, since notify handlers may be run in parallel with acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device() and some of them are installed for ACPI handles that have no struct acpi_device objects attached (i.e. before those objects are created), those notify handlers have to take acpi_scan_lock to prevent races from taking place (e.g. a struct acpi_device is found to be present for the given ACPI handle, but right after that it is removed by acpi_bus_trim() running in parallel to the given notify handler). Moreover, since some of them call acpi_bus_scan() and acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock should be acquired by the callers of these two funtions rather by these functions themselves. For these reasons, make all notify handlers that can handle device addition and eject events take acpi_scan_lock and remove the acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim(). Accordingly, update all of their users to make sure that they are always called under acpi_scan_lock. Furthermore, since eject operations are carried out asynchronously with respect to the notify events that trigger them, with the help of acpi_bus_hot_remove_device(), even if notify handlers take the ACPI scan lock, it still is possible that, for example, acpi_bus_trim() will run between acpi_bus_hot_remove_device() and the notify handler that scheduled its execution and that acpi_bus_trim() will remove the device node passed to acpi_bus_hot_remove_device() for ejection. In that case, the struct acpi_device object obtained by acpi_bus_hot_remove_device() will be invalid and not-so-funny things will ensue. To protect agaist that, make the users of acpi_bus_hot_remove_device() run get_device() on ACPI device node objects that are about to be passed to it and make acpi_bus_hot_remove_device() run put_device() on them and check if their ACPI handles are not NULL (make acpi_device_unregister() clear the device nodes' ACPI handles for that check to work). Finally, observe that acpi_os_hotplug_execute() actually can fail, in which case its caller ought to free memory allocated for the context object to prevent leaks from happening. It also needs to run put_device() on the device node that it ran get_device() on previously in that case. Modify the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-02-02Merge branch 'pci/misc' into nextBjorn Helgaas
* pci/misc: PCI: pciehp: Drop suspend/resume ENTRY messages PCI: Document MPS parameters pci=pcie_bus_safe, pci=pcie_bus_perf, etc PCI: Document hpiosize= and hpmemsize= resource reservation parameters PCI: Use PCI Express Capability accessor PCI: Introduce accessor to retrieve PCIe Capabilities Register PCI: Kill pci_is_reassigndev()
2013-02-02Merge branch 'pci/yinghai-root-bus-hotplug' into nextBjorn Helgaas
* pci/yinghai-root-bus-hotplug: PCI: acpiphp: Remove dead code for PCI host bridge hotplug PCI: acpiphp: Create companion ACPI devices before creating PCI devices PCI: Remove unused "rc" in virtfn_add_bus()
2013-02-02PCI: acpiphp: Remove dead code for PCI host bridge hotplugJiang Liu
Commit 668192b678201d2fff27c "PCI: acpiphp: Move host bridge hotplug to pci_root.c" has moved PCI host bridge hotplug logic from acpiphp to pci_root, but there is still PCI host bridge hotplug related dead code left in acpiphp. So remove those dead code. Now companion ACPI devices are always created before corresponding PCI devices. And the ACPI event handle_hotplug_event_bridge() will be installed only if it has associated PCI device. So remove dead code to handle bridge hot-adding in function handle_hotplug_event_bridge(). Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-02-01PCI: acpiphp: Create companion ACPI devices before creating PCI devicesJiang Liu
With commit 4f535093cf8f6da8c "PCI: Put pci_dev in device tree as early as possible", companion ACPI devices should be created before creating corresponding PCI devices, otherwise it will break the ACPI PCI binding logic. Without this patch, the /sys/bus/pci/devices/.../firmware_node symlink is missing after hot-removing and hot-adding a device with acpiphp. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-02-01PCI: pciehp: Drop suspend/resume ENTRY messagesPaul Bolle
In each suspend and resume cycle my laptop prints these messages at KERN_INFO level: pciehp 0000:00:1c.1:pcie04: pciehp_suspend ENTRY pciehp 0000:00:1c.0:pcie04: pciehp_suspend ENTRY and pciehp 0000:00:1c.0:pcie04: pciehp_resume ENTRY pciehp 0000:00:1c.1:pcie04: pciehp_resume ENTRY Drop these messages, that were probably used to debug the suspend and resume code, but now serve no purpose. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-01-29Merge branch 'acpi-scan' into acpi-cleanupRafael J. Wysocki
The following commits depend on the 'acpi-scan' material.
2013-01-26Merge branch 'pci/yinghai-root-bus-hotplug' into nextBjorn Helgaas
* pci/yinghai-root-bus-hotplug: PCI: Put pci_dev in device tree as early as possible PCI: Skip attaching driver in device_add() PCI: acpiphp: Keep driver loaded even if no slots found PCI/ACPI: Print info if host bridge notify handler installation fails PCI: acpiphp: Move host bridge hotplug to pci_root.c PCI/ACPI: acpiphp: Rename alloc_acpiphp_hp_work() to alloc_acpi_hp_work() PCI: Make device create/destroy logic symmetric PCI: Fix reference count leak in pci_dev_present() PCI: Set pci_dev dev_node early so IOAPIC irq_descs are allocated locally PCI: Add root bus children dev's res to fail list PCI: acpiphp: Add is_hotplug_bridge detection Conflicts: drivers/pci/pci.h
2013-01-26Merge branch 'pci/acpi-scan2' into nextBjorn Helgaas
* pci/acpi-scan2: ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead ACPI: update ej_event interface to take acpi_device ACPI / scan: Add second pass to acpi_bus_trim() ACPI / scan: Change the implementation of acpi_bus_trim() ACPI / scan: Drop the second argument of acpi_bus_trim() ACPI / scan: Drop the second argument of acpi_device_unregister() ACPI: Remove the ops field from struct acpi_device ACPI: remove unused acpi_op_bind and acpi_op_unbind ACPI / scan: Fix check of device_attach() return value.
2013-01-26Merge branch 'pci/yijing-ari' into nextBjorn Helgaas
* pci/yijing-ari: PCI: shpchp: Iterate over all devices in slot, not functions 0-7 PCI: sgihp: Iterate over all devices in slot, not functions 0-7 PCI: cpcihp: Iterate over all devices in slot, not functions 0-7 PCI: pciehp: Iterate over all devices in slot, not functions 0-7 PCI: Consolidate "next-function" functions PCI: Rename pci_enable_ari() to pci_configure_ari() PCI: Enable ARI if dev and upstream bridge support it; disable otherwise
2013-01-26Merge branch 'acpi-scan' into acpi-cleanupRafael J. Wysocki
The following commits depend on the 'acpi-scan' material.
2013-01-26ACPI / scan: Make it clear that acpi_bus_trim() cannot failRafael J. Wysocki
Since acpi_bus_trim() cannot fail, change its definition to a void function, so that its callers don't check the return value in vain and update the callers. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
2013-01-25PCI: acpiphp: Keep driver loaded even if no slots foundYinghai Lu
Could have root bus hot-added later and there may be slots that need acpiphp. The result returned by acpiphp_get_num_slots() is meaningless, because the bridge the slots are under may be added after this function has been called, so drop acpiphp_get_num_slots() and the code using it. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-25PCI: acpiphp: Move host bridge hotplug to pci_root.cYinghai Lu
The acpiphp driver is confusing because it contains partial support for PCI host bridge hotplug as well as support for hotplug of PCI devices. This patch moves the host bridge hot-add support to pci_root.c and adds hot-remove support in pci_root.c. How to test it: if sci_emu patch is applied, find out root bus number to ACPI root name mapping from dmesg or /sys. To remove root bus: echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify To add back root bus: echo "\_SB.PCIB 1" > /sys/kernel/debug/acpi/sci_notify Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-25PCI/ACPI: acpiphp: Rename alloc_acpiphp_hp_work() to alloc_acpi_hp_work()Yinghai Lu
Will need to use it for PCI root bridge hotplug support, so rename *acpiphp* to *acpi* and move to osc.c. Also make kacpi_hotplug_wq static after that. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: Len Brown <lenb@kernel.org> CC: linux-acpi@vger.kernel.org
2013-01-25PCI: acpiphp: Add is_hotplug_bridge detectionYinghai Lu
When system support hotplug bridge with children hotplug slots, we need to make sure that parent bridge get preallocated resource so later when device is plugged into children slot, those children devices will get resource allocated. We do not meet this problem, because for PCIe hotplug card, when acpiphp is used, pci_scan_bridge will set that for us when detect hotplug bit in slot cap. Reported-and-tested-by: Jason Baron <jbaron@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Baron <jbaron@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-25PCI: shpchp: Iterate over all devices in slot, not functions 0-7Yijing Wang
Iterate through devices in a slot by using the upstream bridge's "bus->devices" list instead of assuming they are functions 0-7. It's possible there are several slots on the same pci_bus, so restrict it to only devices matching this slot's device number. ARI (which allows functions 0-255) is a PCIe-only feature, and this is a PCI hotplug driver, so we shouldn't find anything other than functions 0-7, but it's better to iterate the same way as other hotplug drivers. [bhelgaas: changelog, check PCI_SLOT, fix shpchp_unconfigure_device()] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-01-25PCI: sgihp: Iterate over all devices in slot, not functions 0-7Yijing Wang
Iterate through devices in a slot by using the upstream bridge's "bus->devices" list instead of assuming they are functions 0-7. It's possible there are several slots on the same pci_bus, so restrict it to only devices matching this slot's device number. ARI (which allows functions 0-255) is a PCIe-only feature, and this is a PCI hotplug driver, so we shouldn't find anything other than functions 0-7, but it's better to iterate the same way as other hotplug drivers. [bhelgaas: changelog, check PCI_SLOT, fix disable_slot()] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-01-25PCI: cpcihp: Iterate over all devices in slot, not functions 0-7Yijing Wang
Iterate through devices in a slot by using the upstream bridge's "bus->devices" list instead of assuming they are functions 0-7. It's possible there are several slots on the same pci_bus, so restrict it to only devices matching this slot's device number. ARI (which allows functions 0-255) is a PCIe-only feature, and this is a PCI hotplug driver, so we shouldn't find anything other than functions 0-7, but it's better to iterate the same way as other hotplug drivers. [bhelgaas: changelog, check PCI_SLOT, fix cpci_unconfigure_slot()] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-01-25PCI: pciehp: Iterate over all devices in slot, not functions 0-7Yijing Wang
Currently, we enumerate devices in a slot with pci_scan_slot(), then iterate through all the devices we found by looking for functions 0-7. But that's wrong for ARI devices, which may have function numbers up to 255. This means that when we hot-add an ARI device, pciehp only initializes functions 0-7, and other functions don't work correctly. Additionally, if we hot-remove the device, pciehp only removes functions 0-7, leaving stale pci_dev structures for any other functions. This patch fixes the problem by iterating over devices in a slot by using the upstream bridge's "bus->devices" list instead. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-01-19ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() insteadRafael J. Wysocki
The only difference between acpi_bus_scan() and acpi_bus_add() is the invocation of acpi_update_all_gpes() in the latter which in fact is unnecessary, because acpi_update_all_gpes() has already been called by acpi_scan_init() and the way it is implemented guarantees the next invocations of it to do nothing. For this reason, drop acpi_bus_add() and make all its callers use acpi_bus_scan() directly instead of it. Additionally, rearrange the code in acpi_scan_init() slightly to improve the visibility of the acpi_update_all_gpes() call in there. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-01-15ACPI / scan: Drop the second argument of acpi_bus_trim()Rafael J. Wysocki
All callers of acpi_bus_trim() pass 1 (true) as the second argument of it, so remove that argument entirely and change acpi_bus_trim() to always behave as though it were 1. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
2013-01-14PCI: shpchp: Use per-slot workqueues to avoid deadlockBjorn Helgaas
When we have an SHPC-capable bridge with a second SHPC-capable bridge below it, pushing the upstream bridge's attention button causes a deadlock. The deadlock happens because we use the shpchp_wq workqueue to run shpchp_pushbutton_thread(), which uses shpchp_disable_slot() to remove devices below the upstream bridge. When we remove the downstream bridge, we call shpc_remove(), the shpchp driver's .remove() method. That calls flush_workqueue(shpchp_wq), which deadlocks because the shpchp_pushbutton_thread() work item is still running. This patch avoids the deadlock by creating a workqueue for every slot and removing the single shared workqueue. Here's the call path that leads to the deadlock: shpchp_queue_pushbutton_work queue_work(shpchp_wq) # shpchp_pushbutton_thread ... shpchp_pushbutton_thread shpchp_disable_slot remove_board shpchp_unconfigure_device pci_stop_and_remove_bus_device ... shpc_remove # shpchp driver .remove method hpc_release_ctlr cleanup_slots flush_workqueue(shpchp_wq) This change is based on code inspection, since we don't have hardware with this topology. Based-on-patch-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org
2013-01-14PCI: shpchp: Handle push button event asynchronouslyBjorn Helgaas
Use non-ordered workqueue for attention button events. Attention button events on each slot can be handled asynchronously. So we should use non-ordered workqueue. This patch also removes ordered workqueue in shpchp as a result. 486b10b9f4 ("PCI: pciehp: Handle push button event asynchronously") made the same change to pciehp. I split this out from a patch by Yijing Wang <wangyijing@huawei.com> so we fix one thing at a time and to make the shpchp history correspond more closely with the pciehp history. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
2013-01-13PCI: shpchp: Make shpchp_wq non-orderedBjorn Helgaas
e24dcbef93 ("shpchp: update workqueue usage") was described as adding non-ordered shpchp_wq, but it actually made it an *ordered* workqueue. This patch changes shpchp_wq to be non-ordered, as described in the e24dcbef93 commit log and as was done for pciehp by a827ea307b ("pciehp: update workqueue usage"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tejun Heo <tj@kernel.org>
2013-01-12PCI: pciehp: Use per-slot workqueues to avoid deadlockYijing Wang
When we have a hotplug-capable PCIe port with a second hotplug-capable PCIe port below it, removing the device below the upstream port causes a deadlock. The deadlock happens because we use the pciehp_wq workqueue to run pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices below the upstream port. When we remove the downstream PCIe port, we call pciehp_remove(), the pciehp driver's .remove() method. That calls flush_workqueue(pciehp_wq), which deadlocks because the pciehp_power_thread() work item is still running. This patch avoids the deadlock by creating a workqueue for every PCIe port and removing the single shared workqueue. Here's the call path that leads to the deadlock: pciehp_queue_pushbutton_work queue_work(pciehp_wq) # queue pciehp_power_thread ... pciehp_power_thread pciehp_disable_slot remove_board pciehp_unconfigure_device pci_stop_and_remove_bus_device ... pciehp_remove # pciehp driver .remove method pciehp_release_ctrl pcie_cleanup_slot flush_workqueue(pciehp_wq) This is fairly urgent because it can be caused by simply unplugging a Thunderbolt adapter, as reported by Daniel below. [bhelgaas: changelog] Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.com Reported-and-tested-by: Daniel J Blueman <daniel@quora.org> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org