linux-stable.git/drivers/pci/hotplug/pciehp_ctrl.c, branch linux-3.19.y Linux kernel stable tree PCI: Merge multi-line quoted strings 2014-06-11T02:20:42+00:00 Ryan Desfosses ryan@desfo.org 2014-04-19T00:13:50+00:00 227f06470502c4fea3d93df1f12a77e3e37f6263 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: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
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: Ryan Desfosses <ryan@desfo.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
 PCI: Whitespace cleanup 2014-06-11T02:20:19+00:00 Ryan Desfosses ryan@desfo.org 2014-04-19T00:13:49+00:00 3c78bc61f5ef3bc87e7f94f67ec737d2273f120b Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Fix various whitespace errors.

No functional change.

[bhelgaas: fix other similar problems]
Signed-off-by: Ryan Desfosses <ryan@desfo.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
 PCI: pciehp: Cleanup whitespace 2014-02-19T22:05:25+00:00 Bjorn Helgaas bhelgaas@google.com 2014-02-11T22:26:29+00:00 9cad7f582055513fe13a93fee3ddb213656a6a5d Minor whitespace cleanup; no functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
Minor whitespace cleanup; no functional change.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
 PCI: pciehp: Remove a non-existent card, regardless of "surprise" capability 2014-02-19T22:04:14+00:00 Rajat Jain rajatxjain@gmail.com 2014-02-19T02:53:19+00:00 2b3940b60626ac4932fa048cc74f2a872cc4bfb4 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: 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> 
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: 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>
 PCI: pciehp: Don't turn slot off when hot-added device already exists 2014-02-14T17:13:56+00:00 Yijing Wang wangyijing@huawei.com 2014-02-12T00:36:51+00:00 50277c8b06d56f2345e1a0693db46db29fc6d063 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> 
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>
 PCI: pciehp: Add hotplug_lock to serialize hotplug events 2014-02-11T23:13:16+00:00 Rajat Jain rajatxjain@gmail.com 2014-02-05T02:31:11+00:00 50b52fdee050745935d92e7026373edea2647e60 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> 
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>
 PCI: pciehp: Ensure very fast hotplug events are also processed 2014-02-11T23:13:01+00:00 Rajat Jain rajatxjain@gmail.com 2014-02-05T02:30:56+00:00 c4f2f5e4981073a5aa0739f93b6733060cd37648 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> 
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>
 PCI: pciehp: Don't check adapter or latch status while disabling 2014-02-11T23:08:44+00:00 Rajat Jain rajatxjain@gmail.com 2014-02-05T02:30:21+00:00 02e93a8a7c1dcecc1a33ea762a0c041cbb6a0a66 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> 
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>
 PCI: pciehp: Use link change notifications for hot-plug and removal 2014-02-11T01:12:44+00:00 Rajat Jain rajatxjain@gmail.com 2014-02-05T02:29:10+00:00 e48f1b67f668762003e8888eccd7acb71109e874 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> 
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>
 PCI: pciehp: Move Attention & Power Indicator support tests to accessors 2013-12-16T01:00:00+00:00 Bjorn Helgaas bhelgaas@google.com 2013-12-16T00:23:54+00:00 af9ab791e34147952a8b97c998fa257d8292c5d6 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: Bjorn Helgaas <bhelgaas@google.com> 
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: Bjorn Helgaas <bhelgaas@google.com>