I am only guessing, but since this is USB something must associate a device being plugged in to that driver before the code (other than registering existence) will run and produce the device special file. Take a look at some of the other drivers which use the skeleton, and see how they associate a idProduct/idVendor combination. Take a look at which ID shows up for your device under lsusb. Make sure that association is present.
An example of brief listing of all USB devices:
An example is that a TX2 in recovery mode shows up from (limiting to one device by ID):
lsusb -d 0955:7c18
The lsusb response for this example would have “0955:7c18” in it, and a verbose query with sudo would show idVender 0x0955 and idProduct 0x7c18. This is a special case for the TX2 in recovery mode, and there won’t be any kernel driver found (indeed, the “driver package” is user space, and is what flashes a Jetson). Some devices report as a generic class, and won’t use a custom driver; other devices work only with custom devices; a large number of physical devices are actually multiple logical devices using the same cable, and those might use both generic and custom drivers (a programmable keyboard or mouse is an example…they can be used by standard generic class drivers, but programming requires a custom driver).
For the above example, if you wanted a verbose mode listing, then you’d extend the command like this:
<b>sudo</b> lsusb -d 0955:7c18 <b>-vvv</b>
What is the full verbose lsusb of the device you want the driver to trigger? You can attach this as a file to an existing post…if you hover the mouse over the “pencil” icon for editing your post, then a paper clip icon also shows up…and with that you can attach. Or just copy and paste and use the “code” ("</>") formatting.