usbtmc: document why the trigger re-arm result is ignored

A false return from tud_usbtmc_start_bus_read() here does not mean arming
failed: it means the endpoint is already armed, either because the
application re-armed it from its trigger callback or because a transfer is
still queued (usbd_edpt_xfer() reports failure when the endpoint is busy).
Both cases end in STATE_IDLE, so the state cannot disambiguate them either,
and stalling on the result would halt a healthy endpoint.

Co-Authored-By: Claude Opus 5 <[email protected]>

1 files changed, 3 insertions, 0 deletions

diff --git a/src/class/usbtmc/usbtmc_device.c b/src/class/usbtmc/usbtmc_device.c
index e248341ac..0e9978a81 100644
--- a/src/class/usbtmc/usbtmc_device.c
+++ b/src/class/usbtmc/usbtmc_device.c
@@ -511,6 +511,9 @@ bool usbtmcd_xfer_cb(uint8_t rhport, uint8_t ep_addr, xfer_result_t result, uint
               usbd_edpt_stall(rhport, usbtmc_state.ep_bulk_out);
               return false;
             }
+            // Result deliberately ignored: false here means the endpoint is already armed - either the
+            // application re-armed it from its callback, or a transfer is still queued - not that arming
+            // failed. Stalling on it would halt a healthy endpoint.
             tud_usbtmc_start_bus_read();
 
             break;