summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorMichael S. Tsirkin <mst@redhat.com>2017-01-24 19:35:56 +0200
committerBjorn Helgaas <helgaas@kernel.org>2017-02-09 16:41:58 -0600
commit2fd260f03b6a365bad48522f3948463928f91c2c (patch)
treed2873504150accbb405c1d15d892ac181bcc8ec3 /Documentation
parent7ce7d89f48834cefece7804d38fc5d85382edf77 (diff)
downloadblackbird-obmc-linux-2fd260f03b6a365bad48522f3948463928f91c2c.tar.gz
blackbird-obmc-linux-2fd260f03b6a365bad48522f3948463928f91c2c.zip
PCI/AER: Remove unused .link_reset() callback
No hardware seems to actually call .link_reset(), and no driver implements it as more than a nop stub. Drop mentions of the callback from everywhere. It's dropped from the documentation as well, but the doc really needs to be updated to reflect reality better (e.g., on PCIe, slot reset is the link reset). This will be done in a later patch. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/PCI/pci-error-recovery.txt24
1 files changed, 3 insertions, 21 deletions
diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt
index ac26869c7db4..da3b2176d5da 100644
--- a/Documentation/PCI/pci-error-recovery.txt
+++ b/Documentation/PCI/pci-error-recovery.txt
@@ -78,7 +78,6 @@ struct pci_error_handlers
{
int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
int (*mmio_enabled)(struct pci_dev *dev);
- int (*link_reset)(struct pci_dev *dev);
int (*slot_reset)(struct pci_dev *dev);
void (*resume)(struct pci_dev *dev);
};
@@ -104,8 +103,7 @@ if it implements any, it must implement error_detected(). If a callback
is not implemented, the corresponding feature is considered unsupported.
For example, if mmio_enabled() and resume() aren't there, then it
is assumed that the driver is not doing any direct recovery and requires
-a slot reset. If link_reset() is not implemented, the card is assumed to
-not care about link resets. Typically a driver will want to know about
+a slot reset. Typically a driver will want to know about
a slot_reset().
The actual steps taken by a platform to recover from a PCI error
@@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset)
STEP 3: Link Reset
------------------
-The platform resets the link, and then calls the link_reset() callback
-on all affected device drivers. This is a PCI-Express specific state
+The platform resets the link. This is a PCI-Express specific step
and is done whenever a non-fatal error has been detected that can be
-"solved" by resetting the link. This call informs the driver of the
-reset and the driver should check to see if the device appears to be
-in working condition.
-
-The driver is not supposed to restart normal driver I/O operations
-at this point. It should limit itself to "probing" the device to
-check its recoverability status. If all is right, then the platform
-will call resume() once all drivers have ack'd link_reset().
-
- Result codes:
- (identical to STEP 3 (MMIO Enabled)
-
-The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5
-(Resume Operations).
-
->>> The current powerpc implementation does not implement this callback.
+"solved" by resetting the link.
STEP 4: Slot Reset
------------------
OpenPOWER on IntegriCloud