Re: How are USB Rx interrupts periodically polled?

From: Farhan Khan <>
Date: Sun, 08 May 2022 04:21:04 UTC
On May 6, 2022 5:34:54 AM EDT, Hans Petter Selasky <> wrote:
>Hi Farhan,
>On 5/6/22 05:52, Farhan Khan wrote:
>> So, how is the polling of an Rx interrupt done?
>The software side typically queues a DMA job for the hardware. Every 125us the hardware wakes up and sends a packet to the device asking if it has data or not. If it has data, the DMA job completes, and a callback is generated for the USB stack. Then the received data is placed into the receive buffer for the USB transfer.
>This is is the same in OpenBSD and NetBSD, only that there they re-queue the USB transfer behind the scenes.
>Please beware that traditional USB is all polling based. Thunderbolt on the other side is different, and also the security aspects are different.

Hi Hans!

The reason I am asking is because I am trying to port over athn and, after loading the firmware and getting interrupts working (Yay!) I ran into an issue where there is a sleep, triggered after a Tx interrupt, that is only woken up via wakeup(9) in an Rx callback. Yet I do not see where the Rx callback is ever done. As a result, the sleep call returns with a non-zero value.

My current code has the msleep(9) call here:

On the OpenBSD side, the Rx Interrupt pipe is opened with an interval value, which suggests to me that it's autorun every interval, but it's not clear to me.

For context, my email thread on the OpenBSD side is here: (I hope this constitutes as on-topic, apologies!)

- Farhan