Closed mciantyre closed 2 years ago
Yes, the test didn't support HighSpeed devices. What I tested my device, I changed the test locally to compensate for a different endpoint size. I think the proper implementation should detect the device speed and act accordingly. In any case, it would be nice to test request lengths up to 1025 if device supports HighSpeed operation.
I was manually increasing the bulk test request lengths, too. Having the test handle that for us would be nice, and detecting all this at runtime is a simpler approach.
Latest commits implement run-time detection for device speed and bulk endpoint MPS. It LGTM on an i.MX RT; tested with full- and high-speed capable firmware.
The
bulk_loopback
device test sends a zero-length packet (ZLP) from host to device when the bulk endpoint packet size is a multiple of the max packet size (MPS). Before this commit, the MPS was hard-coded to 64, the MPS of the full-speed bulk endpoint. This commit updates the test to use the MPS that matches the full- / high-speed test class's MPS.I was having issues testing a high-speed device with the test suite before this change (compiling both firmware and test suite with
test-class-high-speed
feature). Specifically, the test would fail when trying to read back data from the 65 byte transfer. I think I traced the issue back to this condition, but let me know if you think there might be an issue in my device driver. There's more notes in the commit message.