When software instructs the USB controller (host, device, or OTG) to enter the suspend state, the controller logic immediately sets the suspend status bit. If the controller is busy with a USB transaction, it waits before actually entering the suspend state.
Although the behavior violates the EHCI specification, it does not cause a functional issue because the delay is always less than the 10 milliseconds that the application program must wait before it initiates a forced resume. It also does not affect USB compliance testing.
Minor. Behavior does not adhere to EHCI specification, but is accommodated by the application.
Systems that use the USB controller and the suspend state.
The EHCI specification states the following in the SUSP bit description: "In the Suspend state, the port is sensitive to resume detection. Note that the bit status does not change until the port is suspended and that there may be a delay in suspending a port if there is a transaction currently in progress on the USB."
In the USB controller, the SUSP bit (port_suspend_r) changes immediately when the application sets it and not when the port is actually suspended.
NOTE: This applies to USB Suspend (L2) not to LPM L1 Suspend. There is no issue with the LPM Suspend implementation.
Impact Details: Minor. Although the behavior of the USB Controller violates the EHCI specification statement, it does not cause any functional issue as, according to the EHCI specification, the application must wait for at least 10 milliseconds after a port indicates that it is suspended before initiating a port resume using the Force Port Resume bit.