Documentation/PCI/pci-error-recovery.txt

18 halting all I/O to it.  The goal of a disconnection is to avoid system
30 is reported as soon as possible to all affected device drivers,
46 After a reset and/or a re-enabling of I/O, all drivers are
48 that may be required.  After these have all completed, a final
56 through a large number of contortions to complete recovery. Almost all
102 A driver does not have to implement all of these callbacks; however,
118 is isolated, in that all I/O is blocked: all reads return 0xffffffff,
119 all writes are ignored.
137 All drivers participating in this system must implement this call.
148 		  Driver returns this if it doesn't want to recover at all.
153 If all drivers on the segment/slot return PCI_ERS_RESULT_CAN_RECOVER,
166 >>> implementation uses one kernel thread to notify all devices;
167 >>> thus, if one device sleeps/schedules, all devices are affected.
169 >>> recovery implementation (e.g. waiting for all notification threads
184 DMA), and then calls the mmio_enabled() callback on all affected
192 all drivers on a segment agree that they can try to recover and if no automatic
198 >>> Proposal: All I/O's should be done _synchronously_ from within
227 If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
236 on all affected device drivers.  This is a PCI-Express specific state
244 check its recoverability status. If all is right, then the platform
245 will call resume() once all drivers have ack'd link_reset().
299 at this point.  If all device drivers report success on this
343 The platform will call the resume() callback on all affected device
344 drivers if all drivers on the segment have returned
360 cancel all pending I/O, refuse all new I/O, returning -EIO to
361 higher layers. The device driver should then clean up all of its
368 Note, however, not all failures are truly "permanent". Some are
413 >>> patches implementing error recovery. Not all of these patches are in