This timing thing makes me wonder whether the USB 3.0 controller wouldn't be in fact part of a USB hub. I think depending on how the IC is wired on the board, it could act as a stand alone unit or would wait for the CPU takes control of the communication, meaning setting the hub to behave a specific way. In a standalone configuration, there are timing requirement that needs to be met after a hub reset for which the I2C or SPI interface can succesfully establish communication with he hub. Outside of this time window, the device becomes autonomous and communication is performed across a different high speed link. I don't remeber on top of my head the part number for the hub in question.
For the folks working on the driver side, does it sound somewhat familiar?
As for the comment regarding delays in driver/hardware handshacking, well as an Electronic Engineer, I find this to me a big non-sense. I agree there are some minimum timing requirement that needs to be met, for instance PCI express requires PCI express devices to be ready something like 100ms after reset has been deasserted. If timing is not met the PCI express may not be available.
The better approch in system design is based on feedback theory, and in the digital domain the CPU during peripheral enumeration, or discovery will know what device it should expect. This is I think part of the BIOS, if not it will be the driver, or application to establish device stage.
The basic for handshaking would be somewhat similar to checking if a device such as USB key has been inserted, by the generation of an interrupt (possibly), or trough data polling. If a device as been detected, then it is a matter for the system to establish communication by monitoring specific registers in the controller. Going this route will guarantee proper sequencing irrelevant of the amount of time it has to wait. In the event no errors has been flagged by the controller (through polling or interrupt) and let's say the device died, then only a watchdog would allow the controller to be reset to exit the failed state.
I don't want to insult any unix like programmers, but to me using timing as a pass/fail condition to execute the next piece of code is simply in my opinion a bad programming practice. Inherently, this sounds like a solution to a problem or process that is not understood.