Change Details

Remove delays after writing the administrative queue registers. These delays are from the very earliest days of the driver (they are in the first commit) and were most likely vestiges of the Chatham NVMe prototype card that was used to create this driver. Many of the workarounds necessary for it aren't necessary for standards compliant cards. The original driver had other areas marked for Chatham, but these were not. They are unneeded. There's three lines of supporting evidence. First, the NVMe standards make no mention of a delay time after these registers are written. Second, the Linux driver doesn't have them, even as an option. Third, all my nvme cards work w/o them. Sponsored by: Netflix

After some study of the code and the standard, I think we can just drop the pause(), unconditionally. If we're not initialized, then there's nothing to wait for from a software perspective. If we are initialized, then there might be outstanding I/O. If so, then the qpair 'recovery state' will transition to WAITING in nvme_ctrlr_disable_qpairs, which will ignore any interrupts for items that complete before we complete the reset by setting cc.en=0. If we go on to fail the controller, we'll cancel the outstanding I/O transactions. If we reset the controller, the hardware throws away pending transactions and we retry all the pending I/O transactions. Any transactions that happend to complete before cc.en=0 will have the same effect in the end (doing the same transaction twice is just inefficient, it won't affect the state of the device any differently than having done it once). The standard imposes no wait times here, so it isn't needed from that perspective. Unanswered Question: Do we may need to disable interrupts while we disable in legacy mode since those are level-sensitive.

Remove delays after writingAfter some study of the administrative queue registers.code and the standard, TheseI think we can just drop delays are from the very earliest days of the driver (they are in thethe pause(), unconditionally. If we're not initialized, then there's first commit) and were most likely vestiges of the Chatham NVMenothing to wait for from a software perspective. If we are initialized, prototype card that was used to create this driver.then there might be outstanding I/O. If so, Many of thethen the qpair 'recovery workarounds necessary for it aren't necessary for standards compliantstate' will transition to WAITING in nvme_ctrlr_disable_qpairs, which cards. The original driver had other areas marked for Chatham, but thesewill ignore any interrupts for items that complete before we complete were not. They are unneeded. There's three lines of supporthe reset by setting evidencecc.en=0. FirstIf we go on to fail the controller, the NVMe standards make no mention of a delay time after thesewe'll cancel the outstanding I/O registers are written. Second, the Linux driver doesn't have themtransactions. If we reset the controller, eventhe hardware throws away apending transactions an opd we retry all the pending I/O transactions. Third, all my nvme cards work w/o themAny transactions that happend to complete before cc.en=0 will have the same effect in the end (doing the same transaction twice is just inefficient, it won't affect the state of the device any differently than having done it once). Sponsored by: NetflixThe standard imposes no wait times here, so it isn't needed from that perspective. Unanswered Question: Do we may need to disable interrupts while we disable in legacy mode since those are level-sensitive.