On macOS 12.6 running libusb 1.0.26, the host was seen to sometimes
make an incomplete ClearFeature(ENDPOINT_HALT) request when
ClearPipeStallBothEnds was called from libusb_cancel_transfer.
The host would send the SETUP packet, and the firmware would
call usb_transfer_schedule_ack to acknowledge the upcoming IN
token. However, the host would then not send the IN token,
proceeding directly to the next SETUP.
Since an empty transfer was queued to schedule the ACK, the
firmware would leak one transfer from the free_transfers list.
After a few iterations of this, the firmware would run out of
free transfers and the next request would hang waiting for one.
Fix this by flushing the transfer queues for the control endpoint
when a new SETUP is received, since that token implicitly cancels
any previously ongoing request.
This avoids a confusing condition when hackrf_transfer is reading from
stdin with -R in which it does not repeat previous data but repeatedly
restarts reading new data after the user types Ctrl-D to indicate EOF.
The -R option should repeat previous data or should do nothing if the
input file cannot be rewound.
Previously these calls were leaving the amplifiers on, since the
control settings passed were missing SWITCHCTRL_NO_TX_AMP_PWR and
SWITCHCTRL_NO_RX_AMP_PWR. Use the predefined SWITCHCTRL_SAFE here.
Also move these calls before setting the GPIO pins to output mode,
to avoid driving them to the wrong states briefly first.
Where our callback is called with a status other than COMPLETED,
something abnormal has happened and we no longer want to either
submit further transfers or await a flush. So clear the streaming
and flush flags, and proceed to transfer_finished.
Do the same in the case where libusb_submit_transfer fails when
called to submit the flush transfer.
Fixes a bug introduced in 8a9af7a: Statistics skipped for initial
buffers not only when preloaded in TX mode but also in RX mode with no
preloading.
The total bytes transferred may appear inflated in RX mode when
receiving a small number of samples with -n, but the stats represent
data transferred over USB, some of which may have been discarded by the
host.
Instead of sending a signal to the process group, get our own process ID
and send the signal to it. This fixes a bug that prevented termination
when called from a script.