After some study ofRemove delays after writing the code and the standard,administrative queue registers. I think we can just dropThese
the pause(), unconditionally. If we're not initialized, then there'sdelays are from the very earliest days of the driver (they are in the
nothing to wait for from a software perspective. If we are initialized,first commit) and were most likely vestiges of the Chatham NVMe
then there might be outstanding I/O. If so,prototype card that was used to create this driver. then the qpair 'recoveryMany of the
state' will transition to WAITING in nvme_ctrlr_disable_qpairs, whichworkarounds necessary for it aren't necessary for standards compliant
will ignore any interrupts for items that complete before we completecards. The original driver had other areas marked for Chatham, but these
the reset by setwere not. They are unneeded. There's three lines of supporting cc.en=0evidence.
If we go on to fail the controllerFirst, we'll cancel the outstanding I/Othe NVMe standards make no mention of a delay time after these
transactions. If we reset the controllerregisters are written. Second, the Linux driver doesn't have them, the hardware throws awayeven
pending transactionas and we retry all the pending I/O transac options. 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)Third, all my nvme cards work w/o them.
The standard imposes no wait times hereTo be safe, so it isn't needed from thatadd a write barrier between setting up the admin queue and
perspective.
Unanswered Question: Do we may need to disable interrupts while we
disable in legacy mode since those are level-sensitiveenabling the controller.