If possible for your use case, consider using the userland HID API (which, aside from being safer in userland, is a C API):
If you must use a kext, though, you’re going to need to both interact tightly with various IOKit objects and write at least one subclass of IOService to represent your device. Now, the IOKit C++ API is pretty close to a best case for hypothetical bindings generators: it’s written in a restricted (old-fashioned) subset of C++ with no templates (or exceptions, or namespaces), so it’s easy to map types, and the API is designed so that basically everything is on the heap and passed around as raw pointers, so there’s no automatic copy/move constructor invocation or operator overloading that could cause impedance mismatch with the target language. However, I don’t know if any such generator exists: there was a blog post last year about something called “cxx2rust”, but I don’t know if the code was ever finished or released. If you have to do the binding manually, I suspect the code to translate from one world to the other will be larger than the whole driver would be if you just wrote it all in C++ - most drivers for relatively simple things like HID devices don’t need that much code, after all.