- 09 6月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
The commit referenced below deferred waiting for command completion until the start of the next command, allowing hardware to do the latching asynchronously. Unfortunately, being ready to accept a new command is the only indication we have that the previous command is completed. In cases where we need that state change to be enabled, we must still wait for completion. For instance, pciehp_reset_slot() attempts to disable anything that might generate a surprise hotplug on slots that support presence detection. If we don't wait for those settings to latch before the secondary bus reset, we negate any value in attempting to prevent the spurious hotplug. Create a base function with optional wait and helper functions so that pcie_write_cmd() turns back into the "safe" interface which waits before and after issuing a command and add pcie_write_cmd_nowait(), which eliminates the trailing wait for asynchronous completion. The following functions are returned to their previous behavior: pciehp_power_on_slot pciehp_power_off_slot pcie_disable_notification pciehp_reset_slot The rationale is that pciehp_power_on_slot() enables the link and therefore relies on completion of power-on. pciehp_power_off_slot() and pcie_disable_notification() need a wait because data structures may be freed after these calls and continued signaling from the device would be unexpected. And, of course, pciehp_reset_slot() needs to wait for the scenario outlined above. Fixes: 3461a068 ("PCI: pciehp: Wait for hotplug command completion lazily") Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.17+
-
- 24 9月, 2014 3 次提交
-
-
由 Yinghai Lu 提交于
During pciehp initialization, we previously wrote two hotplug commands: pciehp_probe pcie_init pcie_disable_notification pcie_write_cmd # command 1 pcie_init_notification pcie_enable_notification pcie_write_cmd # command 2 For controllers with errata like Intel CF118, we previously waited for a timeout before issuing the second hotplug command because the first command only updates interrupt enable bits and is not a "real" hotplug command, so the controller doesn't report Command Completed for it. But there's no need to disable notifications in the first place. If BIOS left them enabled, we could easily take an interrupt before disabling them, so there's no benefit in disabling them for the tiny window before we enable them. Drop the unnecessary pcie_disable_notification() call. [bhelgaas: changelog] Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.htmlSigned-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Yinghai Lu 提交于
Add more Slot Control debug output and move one print after pcie_write_cmd() to be consistent with other debug output. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Yinghai Lu 提交于
When we warned about a timeout on a hotplug command, we previously printed the time between calls to pcie_write_cmd(), without accounting for any time spent actually waiting. Consider this sequence: pcie_write_cmd write SLTCTL cmd_started = jiffies # T1 pcie_write_cmd pcie_wait_cmd now = jiffies # T2 wait_event_timeout # we may wait here if (timeout) ctrl_info("Timeout on command issued %u msec ago", jiffies_to_msecs(now - cmd_started)) We previously printed (T2 - T1), but that doesn't include the time spent in wait_event_timeout(). Fix this by using the current jiffies value, not the one cached before calling wait_event_timeout(). [bhelgaas: changelog, use current jiffies instead of adding timeout] Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time") Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 23 9月, 2014 1 次提交
-
-
由 Yinghai Lu 提交于
pcie_poll_cmd() take msecs instead of jiffies, so convert timeout to msecs. Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time") Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 13 9月, 2014 1 次提交
-
-
由 Bjorn Helgaas 提交于
4283c70e ("PCI: pciehp: Make pcie_wait_cmd() self-contained") added a cache of the most recent command written to the Slot Control register. This register is only 16 bits wide, but the cache ("slot_ctrl") is 32 bits. Reduce slot_ctrl to a u16 so it matches the register size. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 9月, 2014 1 次提交
-
-
由 Bjorn Helgaas 提交于
Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold), normally generates a hot-remove event that unbinds the driver. Some drivers expect to remain bound to a device even while they power it off and back on again. This can be dangerous, because if the device is removed or replaced while it is powered off, the driver doesn't know that anything changed. But some drivers accept that risk. Add pci_ignore_hotplug() for use by drivers that know their device cannot be removed. Using pci_ignore_hotplug() tells the PCI core that hot-plug events for the device should be ignored. The radeon and nouveau drivers use this to switch between a low-power, integrated GPU and a higher-power, higher-performance discrete GPU. They power off the unused GPU, but they want to remain bound to it. This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") but extends it to work with both acpiphp and pciehp. This fixes a problem where systems with dual GPUs using the radeon drivers become unusable, freezing every few seconds (see bugzillas below). The resume of the radeon device may also fail, e.g., This fixes problems on dual GPU systems where the radeon driver becomes unusable because of problems while suspending the device, as in bug 79701: [drm] radeon: finishing device. radeon 0000:01:00.0: Userspace still has active objects ! radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free ... WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]() trying to unbind memory from uninitialized GART ! or while resuming it, as in bug 77261: radeon 0000:01:00.0: ring 0 stalled for more than 10158msec radeon 0000:01:00.0: GPU lockup ... radeon 0000:01:00.0: GPU pci config reset pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1) radeon 0000:01:00.0: GPU reset succeeded, trying to resume *ERROR* radeon: dpm resume failed radeon 0000:01:00.0: Wait for MC idle timedout ! Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: NShawn Starr <shawn.starr@rogers.com> Reported-by: NJose P. <lbdkmjdf@sharklasers.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Acked-by: NRajat Jain <rajatxjain@gmail.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NDave Airlie <airlied@redhat.com> CC: stable@vger.kernel.org # v3.15+
-
- 08 7月, 2014 1 次提交
-
-
由 Myron Stowe 提交于
During PCIe hot-plug initialization - pciehp_probe() - data structures related to slot capabilities are set up. As part of this set up, ISRs are put in place to handle slot events and all event bits are cleared out. This patch adds the Data Link Layer State Changed (PCI_EXP_SLTSTA_DLLSC) Slot Status bit to the event bits that are cleared out during initialization. If the BIOS doesn't clear DLLSC before handoff to the OS, pciehp notices that it's set and interprets it as a new Link Up event, which results in spurious messages: pciehp 0000:82:04.0:pcie24: slot(4): Link Up event pciehp 0000:82:04.0:pcie24: Device 0000:83:00.0 already exists at 0000:83:00, cannot hot-add pciehp 0000:82:04.0:pcie24: Cannot add device at 0000:83:00 Prior to e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal"), pciehp ignored DLLSC. Reference: PCI-SIG. PCI Express Base Specification Revision 4.0 Version 0.3 (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah). [bhelgaas: add e48f1b67 ref and stable tag] Fixes: e48f1b67 ("PCI: pciehp: Use link change notifications for hot-plug and removal") Link: https://bugzilla.kernel.org/show_bug.cgi?id=79611Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+
-
- 06 7月, 2014 1 次提交
-
-
由 Rajat Jain 提交于
"no_cmd_complete" is only used once, and it duplicates read-only information we already have in the cached Slot Capabilities value. Remove the field and use the existing macro NO_CMD_CMPL() instead. [bhelgaas: changelog] Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 18 6月, 2014 3 次提交
-
-
由 Bjorn Helgaas 提交于
We use incorrect logic to decide whether a PCIe hotplug controller generates command completion events. 5808639b ("pciehp: fix slow probing") assumed that the Slot Status "Command Completed" bit was set only for commands affecting slot power, indicators, or electromechanical interlock. That assumption is false: per sec. 6.7.3.2 of PCIe spec r3.0, a write targeting any portion of the Slot Control register is a command, and (if command completed events are supported) software must wait for a command to complete before issuing the next command. 5808639b was to fix boot-time timeouts (see bugzilla below) on a Lenovo Thinkpad R61 with an Intel hotplug controller. The controller probably has the Intel CF118 erratum, which means it doesn't report Command Completed unless the Slot Control power, indicator, or interlock bits are changed. This causes a timeout because pciehp always waits for Command Complete (if supported), regardless of which bits are changed. Remove the incorrect logic because the timeouts have been addressed differently by these changes: PCI: pciehp: Wait for hotplug command completion lazily PCI: pciehp: Compute timeout from hotplug command start time Link: https://bugzilla.kernel.org/show_bug.cgi?id=10751 Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
If we issue a hotplug command, go do something else, then come back and wait for the command to complete, we don't have to wait the whole timeout period, because some of it elapsed while we were doing something else. Keep track of the time we issued the command, and wait only until the timeout period from that point has elapsed. For controllers with errata like Intel CF118, we previously timed out before issuing the second hotplug command: At time T1 (during boot): - Write DLLSCE, ABPE, PDCE, etc. to Slot Control At time T2 (hotplug event): - Wait for command completion (CC) in Slot Status - Timeout at T2 + 1 second because CC is never set in Slot Status - Write PCC, PIC, etc. to Slot Control With this change, we wait until T1 + 1 second instead of T2 + 1 second. If the hotplug event is more than 1 second after the boot-time initialization, we won't wait for the timeout at all. We still emit a "Timeout on hotplug command" message if it timed out; we should see this on the first hotplug event on every controller with this erratum, as well as on real errors on controllers without the erratum. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
由 Bjorn Helgaas 提交于
Previously we issued a hotplug command and waited for it to complete. But there's no need to wait until we're ready to issue the *next* command. The next command will probably be much later, so the first one may have already completed and we may not have to actually wait at all. Because of hardware errata, some controllers generate command completion events for some commands but not others. In the case of Intel CF118 (see spec update reference), the controller indicates command completion only for Slot Control writes that change the value of the following bits: Power Controller Control Power Indicator Control Attention Indicator Control Electromechanical Interlock Control Changes to other bits, e.g., the interrupt enable bits, do not cause the Command Completed bit to be set. Controllers from AMD and Nvidia are reported to have similar errata. These errata cause timeouts when pcie_enable_notification() enables interrupts. Previously that timeout occurred at boot-time. With this change, the timeout occurs later, when we change the state of the slot power, indicators, or interlock. This speeds up boot but causes a timeout at the first hotplug event on the slot. Subsequent events don't timeout because only the first (boot-time) hotplug command updates Slot Control without touching the power/indicator/interlock controls. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 17 6月, 2014 1 次提交
-
-
由 Bjorn Helgaas 提交于
pcie_wait_cmd() waits for the controller to finish a hotplug command. Move the associated logic (to determine whether waiting is required and whether we're using interrupts or polling) from pcie_write_cmd() to pcie_wait_cmd(). No functional change. Tested-by: Rajat Jain <rajatxjain@gmail.com> (IDT 807a controller) Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 11 6月, 2014 2 次提交
-
-
由 Ryan Desfosses 提交于
Merge quoted strings that are broken across lines into a single entity. The compiler merges them anyway, but checkpatch complains about it, and merging them makes it easier to grep for strings. No functional change. [bhelgaas: changelog, do the same for everything under drivers/pci] Signed-off-by: NRyan Desfosses <ryan@desfo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Ryan Desfosses 提交于
Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: NRyan Desfosses <ryan@desfo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 25 4月, 2014 1 次提交
-
-
由 Rajat Jain 提交于
In case of a spurious "cmd completed", pcie_write_cmd() does not clear it, but yet expects more "cmd completed" events to be generated. This does not happen because the previous (spurious) event has not been acknowledged. Fix that. Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 20 2月, 2014 1 次提交
-
-
由 Rajat Jain 提交于
In case a card is physically yanked out, it should immediately be removed, regardless of the "surprise" capability bit. Thus: - Always handle the physical removal - regardless of the "surprise" bit. - Don't use "surprise" capability when making decisions about enabling presence detect notifications. - Reword the comments to indicate the intent. Signed-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 12 2月, 2014 4 次提交
-
-
由 Rajat Jain 提交于
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: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
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: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
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 2debd928 ("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.comSigned-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
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.comSigned-off-by: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 11 2月, 2014 2 次提交
-
-
由 Rajat Jain 提交于
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: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Rajat Jain 提交于
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: NRajat Jain <rajatxjain@gmail.com> Signed-off-by: NRajat Jain <rajatjain@juniper.net> Signed-off-by: NGuenter Roeck <groeck@juniper.net> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 16 12月, 2013 7 次提交
-
-
由 Bjorn Helgaas 提交于
Previously, the caller checked ATTN_LED() or PWR_LED() to see whether the slot has indicators before setting the indicator state. That clutters the caller unnecessarily, so this moves the test inside the callees. The test may not even be necessary; per spec it should be harmless to try to turn on a non-existent LED. But checking first does avoid unnecessary hotplug commands. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Add symbolic constants for the PCIe Slot Control indicator and power control fields defined by spec and use them instead of open-coded hex constants. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Use the PCI_EXP_SLTSTA definitions, not 0x1f, when clearing Slot Status bits. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
It's simpler to test the PCI_EXP_SLTSTA_PFD bit directly and to write the constant back to PCI_EXP_SLTSTA. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
We already have the vendor/device IDs from pci_setup_device(), so drop that info and print things that will be more useful for debugging: the slot number and presence of button/indicators/link active reporting/etc. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
These functions: pcie_enable_notification() pciehp_power_off_slot() pciehp_get_power_status() pciehp_get_attention_status() pciehp_set_attention_status() pciehp_get_latch_status() pciehp_get_adapter_status() pcie_write_cmd() now always return success, so this patch makes them void and drops the error-checking code in their callers. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
There's not much point in checking the return value from every config space access because the only likely errors are design-time things like unaligned accesses or invalid register numbers. The checking clutters the code significantly, so this patch removes it. No functional change. Reference: http://lkml.kernel.org/r/CA+55aFzP4xEbcNmZ+MS0SQ3LrULzSq+dBiT_X9U-bPpR-Ukgrw@mail.gmail.comSigned-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 15 12月, 2013 1 次提交
-
-
由 Bjorn Helgaas 提交于
The pciehp_readw() and pciehp_writew() wrappers only look up the pci_dev and call the PCIe Capability accessors, so we can make things a little more straightforward by just using the PCIe Capability accessors directly. No functional change. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 15 11月, 2013 1 次提交
-
-
由 Bjorn Helgaas 提交于
Fix whitespace, capitalization, and spelling errors. No functional change. I know "busses" is not an error, but "buses" was more common, so I used it consistently. Signed-off-by: Marta Rybczynska <rybczynska@gmail.com> (pci_reset_bridge_secondary_bus()) Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 8月, 2013 1 次提交
-
-
由 Alex Williamson 提交于
PCIe hotplug has a bus per slot, so we can just use a normal secondary bus reset. However, if a slot supports surprise removal, a bus reset can be seen as a presence detection change triggering a hot-remove followed by a hot-add. Disable presence detection from triggering an interrupt or being polled around the bus reset. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 04 7月, 2013 1 次提交
-
-
由 Kees Cook 提交于
For the workqueue creation interfaces that do not expect format strings, make sure they cannot accidently be parsed that way. Additionally, clean up calls made with a single parameter that would be handled as a format string. Many callers are passing potentially dynamic string content, so use "%s" in those cases to avoid any potential accidents. Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 13 1月, 2013 1 次提交
-
-
由 Yijing 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.comReported-and-tested-by: NDaniel J Blueman <daniel@quora.org> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org
-
- 24 8月, 2012 1 次提交
-
-
由 Jiang Liu 提交于
Use PCI Express Capability access functions to simplify pciehp. Signed-off-by: NJiang Liu <jiang.liu@huawei.com> Signed-off-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
-
- 13 7月, 2012 1 次提交
-
-
由 Yinghai Lu 提交于
Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
-
- 15 2月, 2012 3 次提交
-
-
由 Yinghai Lu 提交于
On a system with a repeater on the system board to support gen2 hotplug, we found that when an ExpressModule is removed from some slots, /var/log/messages will be full of "card present/not present" warnings. It turns out the root complex is continually trying to train the link to the repeater because the repeater has not been reset. This patch will disable the link at removal time to allow the repeater to be reset properly. This also prevents a potential AER message at removal time. Also, when testing hotplug on a system under development, we found if we boot the system without an EM installed, and later hot-add an EM, it does not work with Linux, but another OS is ok. The root cause is that BIOS left link disabled when slot was empty at boot time, and other OS is modifying the link disable bit in link ctrl during power on/off. So we should do the same thing to disable/enable link during power off/on. -v2: check link DLLA bit instead of 100ms waiting. Separate link disable/enable functions to another patch. Signed-off-by: NYinghai Lu <yinghai.lu@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Will use it during power off/on of slots Signed-off-by: NYinghai Lu <yinghai.lu@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Yinghai Lu 提交于
Will use it for link disable status checking. Signed-off-by: NYinghai Lu <yinghai.lu@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-