diff options
| author | Michael S. Tsirkin <mst@redhat.com> | 2017-01-24 19:35:56 +0200 |
|---|---|---|
| committer | Bjorn Helgaas <helgaas@kernel.org> | 2017-02-09 16:41:58 -0600 |
| commit | 2fd260f03b6a365bad48522f3948463928f91c2c (patch) | |
| tree | d2873504150accbb405c1d15d892ac181bcc8ec3 /Documentation/PCI | |
| parent | 7ce7d89f48834cefece7804d38fc5d85382edf77 (diff) | |
| download | linux-2fd260f03b6a365bad48522f3948463928f91c2c.tar.gz linux-2fd260f03b6a365bad48522f3948463928f91c2c.tar.bz2 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/PCI')
| -rw-r--r-- | Documentation/PCI/pci-error-recovery.txt | 24 |
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 ------------------ |