usb3 device power state goes to U2 & already submitted INT IN URB not able to wake up device to U0

Currently, I’m facing one weird issue with my custom Windows USB driver.
So I know in USB 3.0 the interrupt xfer mechanism is totally changed i.e from polling to async notification.
From the driver perspective, I have submitted my Interrupt URB immediately after driver registration when the device will probe on the USB port.
That means my driver will always in a listening mode for any Interrupt packets.

But unfortunately, my device goes into U2 state whenever there is no bus activity like other endpoints operations. and I’m not able to read Interrupt IN packets from the device. over here at device side IN transfer to host is successfully but after that, on USB analyzer there is not activity.

My Question is, If one of my endpoint already submitted URB then why device is not wakeup to U0?
I have also referring deferred packets concept to resolve this problem and found that in LinkControlWord there is Deferred bit… If i set it to 1 than it should works
How can I set that bit?

https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/common-hardware-problems-with-u1-or-u2-implementation
USB 3.0 spec section c.1.2.2 Packet Deferring

Bhoomil_Chavda wrote:

That means my driver will always in a listening mode for any Interrupt packets.

Well, that’s only true if you resubmit the read URB immediately after
processing a completed one.  Is that how you do it?  The old “continuous
reader” model?

But unfortunately, my device goes into U2 state whenever there is no bus activity like other endpoints operations.

The U2 state only affects the link, not your device.  The link is
supposed to go into a low-power state after you return NRDY, but your
device shouldn’t be changing its own power state if it still has work to
do.  The link power state is between your chip’s USB engine and the hub
port.

My Question is, If one of my endpoint already submitted URB then why device is not wakeup to U0?

That’s a device firmware question.  If you have issued an NRDY, then the
hub is waiting for your device to send ERDY before it can send another
IN token.  When your device has data, there must be some firmware API
call to wake up your USB engine so it can send ERDY.

I have also referring deferred packets concept to resolve this problem and found that in LinkControlWord there is Deferred bit… If i set it to 1 than it should works

How can I set that bit?

You are looking in the wrong place.  The problem is in your firmware.

thanks, Tim for your replay. Still, investigate the problem. but for a simplified solution as of now, I have disabled the power down mode of firmware and it is working good.