summaryrefslogtreecommitdiff
path: root/tmk_core
diff options
context:
space:
mode:
authorStefan Kerkmann <karlk90@pm.me>2022-05-15 00:17:14 +0200
committerGitHub <noreply@github.com>2022-05-14 23:17:14 +0100
commit4d107feca9621ee3f342507136b04f176e8f2320 (patch)
tree87bab25aac3ec044f4bd1322a57f19d240fb22c4 /tmk_core
parentda632895051558740ca1ca8ecb607a846e2384d7 (diff)
Check for ongoing transfers on the OUT endpoint (#16974)
...when attempting to start a receiving USB transfer. Previously, we would check on the IN endpoint which is the transmitting part of the USB endpoint. This is wrong and lead to two USB transfers being started immediately after each other in case of e.g. RAW HID endpoints: 1. When finishing an OUT transfer the low level USB driver calls the out_cb callback, which in turn initiates another OUT transfer by calling qmkusbDataReceived. 2. When the raw hid receive channel runs empty inside the raw_hid task, another OUT transfer is started to potentially fill the channel again. This happens by calling ibnotify. Both events occur directly after each other, thus triggering the bug.
Diffstat (limited to 'tmk_core')
-rw-r--r--tmk_core/protocol/chibios/usb_driver.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/tmk_core/protocol/chibios/usb_driver.c b/tmk_core/protocol/chibios/usb_driver.c
index 4de060f306..ad45f9b1da 100644
--- a/tmk_core/protocol/chibios/usb_driver.c
+++ b/tmk_core/protocol/chibios/usb_driver.c
@@ -60,7 +60,7 @@ static bool qmkusb_start_receive(QMKUSBDriver *qmkusbp) {
}
/* Checking if there is already a transaction ongoing on the endpoint.*/
- if (usbGetReceiveStatusI(qmkusbp->config->usbp, qmkusbp->config->bulk_in)) {
+ if (usbGetReceiveStatusI(qmkusbp->config->usbp, qmkusbp->config->bulk_out)) {
return true;
}