The USB side is the side where the device special file will show up upon driver load (assuming USB serial UART and not direct wired UART). The driver should not load if no device is present (you can force this, but it doesn’t mean much). Loading a driver (indicating hardware found) should generate a device special file (not necessarily a name you expect since udev might rename this).
Insmod of a driver capable of handling a serial UART using a custom manufacturer/device ID would be the same as not finding hardware, unless udev tells the driver the two are compatible. No matter how a driver is forced to load, if the driver does not know it can pair with that hardware (presumably via IDs for USB), then the device special file will not show up.
In the case of a serial UART directly wired into the unit, then the device tree would provide information to tell the driver what is there and where to find it…essentially something a USB side would inform the driver about. udev can still be involved in renaming for integrated devices wired to the memory controller.
Usually an association of which driver handles the device will be found in
dmesg. In the case of USB insert, then that information appears upon insert. If that messages stops with manufacturer and device ID, and does not mention device special file or driver, then likely either the driver is missing or the driver does not know it is compatible.
One reason I keep looking for the plain “
lsusb” output, without anything else, is that I want to see the list of IDs. Finding that information via “
ls /dev/ttyUSB*” somewhat depends on successful driver load and pairing, but I am interested in the raw USB broadcast, not the result of the broadcast.
Assuming this is the Jetson itself (but it doesn’t really matter), run “
dmesg --follow” on one terminal, and run “
watch -n 1 lsusb” on another terminal, and see what happens when you plug in the connector. I am assuming you are interested in the side with the USB insert. This provides the details to know what issues might cause a driver to not associate (e.g., manufacturer customization).
For a driver load to create a device special file with any meaning it has to have a specific piece of hardware to associate with (presumably USB, but possibly integrated to a memory controller and set up with device tree).
mknod creates a file, but it has no meaning since the driver is not loaded in combination with being initialized for a specific piece of hardware.