cp2112: Check status errors and bound I2C waits

[ptudor_ptudor.net]

Summary

A USB error during an I2C transfer can leave cp2112(4) blocked indefinitely, preventing USB detach and even reboot from completing.

cp2112iic_check_req_status() uses the status response without checking whether the exchange succeeded. A failed exchange can therefore reuse a stale busy response and retry indefinitely. The output callback also records an error without marking the transfer done, causing its waiter to sleep again.

Check the exchange result before using the response, and mark failed output transfers complete. Use absolute deadlines based on USB_DEFAULT_TIMEOUT (five seconds) for output and input condition-variable waits, and stop repeated busy status responses after the status loop's own deadline. Clear pending input state when the paired output request fails. These are per-wait and status-loop bounds; they do not impose a single five-second limit on the entire I2C operation.

Add HQ_HID_IGNORE entries for both VID/PID pairs matched by cp2112, so usbhid does not claim the interface ahead of the bridge driver. Define LUMANATE in usbdevs and use USB_VENDOR_LUMANATE for the existing 0x1009 entry in both device tables.

PR: 300017

Related hardware testing: D60989, the RNG90 I2C slave driver. This controller fix applies independently of that driver.

Test Plan

All hardware testing reported here used CP2112-F02 (Get Version Information: part 0x0c, version 0x02), VID/PID 10c4:ea90. The lifecycle and soak results below were obtained with diff 191424, before the vendor-name cleanup.

• Rebuilt cp2112 and hidquirk on FreeBSD 15.1-RELEASE-p6 amd64 with the standard kernel warning settings and -Werror. The C source files on the recorded main base are identical to the unpatched release files. Generated USB headers from the recorded main catalogue with the added vendor entry, and verified USB_VENDOR_LUMANATE is 0x1009.
• Built the accepted version and the vendor-name cleanup with the same native toolchain and headers. Both resulting modules are byte-identical after removing debug information.
• Rebuilt and installed the matching GENERIC kernel and module set for diff 191424, then rebooted with the CP2112-specific loader quirk removed. The F02 bridge attached to cp2112 with usbhid still enabled and no USB/HID quirk overrides in the boot environment.
• Three controller resets with concurrent raw reads and RNG90 entropy collection completed cleanly. Each reader returned ENXIO on disconnect, and each replacement attachment resumed feeding with zero error counters.
• A subsequent one-hour run completed with steady entropy collection and zero RNG90 error or health counters. Kernel messages were unchanged, and the installed kernel/module hashes still matched.
• Physical removal during continuous raw reads and entropy collection completed detach without a hang. The interrupted reader returned EIO. Reconnecting automatically restored feeding, fresh raw reads succeeded, and a further recovery check found zero RNG90 error or health counters and no continuing kernel messages.
• Compact and full-context patches pass git apply --check against the recorded base. The updated CP2112 patch and the RNG90 patch also apply together in either order. FreeBSD checkstyle9.pl reports no errors or warnings.
• The alternate 1009:ea90 entry is compile-tested only.
• I plan to repeat hardware testing on CP2112-F03 in about a week and if there is anything to note, I will report those results at that time.

[adrian]

@wulf any comments re: i2c'ness?

[adrian]

This /looks/ fine to me, but there's too much commenting for what's really self evident stuff.

sys/dev/usb/misc/cp2112.c

75

We don't need such a verbose comment here. Just delete it.

977

We don't need comment here. error handling is self explanatory here.

[wulf]

sys/dev/usb/misc/cp2112.c

82

(USB_DEFAULT_TIMEOUT * SBT_1MS) looks better here.

[wulf]

sys/dev/usb/misc/cp2112.c

261

This VID/PIDs should be added tp sys/dev/hid/hidquirk.c quirk table with HQ_HID_IGNORE mark.

[ptudor_ptudor.net]

Thanks, I've removed the two comments and changed the timeout to USB_DEFAULT_TIMEOUT * SBT_1MS (five seconds). Each report wait and status loop retains its own absolute deadline.

I've also added HQ_HID_IGNORE entries for both VID/PID pairs already matched by cp2112, including the alternate 0x1009 vendor ID, so usbhid leaves those interfaces to the bridge driver. The updated diff has full context.

I rebuilt and installed the matching 15.1-RELEASE-p6 GENERIC kernel and modules, then rebooted with the manual USB HID-ignore quirk removed. The 10c4:ea90 bridge attached to cp2112 with usbhid still enabled. Three controller resets with raw reads and entropy collection active detached and resumed collection cleanly.

A subsequent one-hour run completed with steady entropy collection, zero RNG90 errors or health failures, and no new kernel messages. Physically unplugging during active reads also completed without a hang; reconnecting automatically restored entropy collection, and fresh raw reads succeeded. The alternate 1009:ea90 entry is compile-tested only.

The patch applies cleanly to the recorded main base, and checkstyle9.pl reports no errors or warnings.

[wulf]

sys/dev/hid/hidquirk.c

119

You may add vendor LUMANATE 0x1009 Lumanate to sys/dev/usb/usbdevs file and replace 0x1009 with LUMANATE here and in cp2112_devs array too. I do not insist on it.

[ptudor_ptudor.net]

Thanks, I've added LUMANATE (0x1009) to usbdevs and used USB_VENDOR_LUMANATE in both the HID quirk and cp2112_devs. The updated diff has full context.

I regenerated the USB headers and rebuilt both modules on FreeBSD 15.1-RELEASE-p6 with the standard kernel warning settings and -Werror. Compared with builds of the accepted diff, both modules are byte-identical after removing debug information. Patch application and style checks pass.

To clarify for future readers the hardware coverage, all hardware testing reported here has been on CP2112-F02: part 0x0c, version 0x02, VID/PID 10c4:ea90. I plan to repeat hardware testing on CP2112-F03 in about a week and if there is anything to note, I will report those results then. The alternate 1009:ea90 entry remains compile-tested only.