You’ll need to describe your exact issue since even tiny differences might matter. Also, is this a dev kit, or does this use a third party carrier board?
Meanwhile, some basic information might help as a place to get started…
The files “/dev/ttyUSB*” and “/dev/ttyACM*” are serial UART files which result from having a particular brand of USB-to-serial-UART chipsets. One brand results in ttyUSB* when pluggging it in to USB, the other brand results in ttyACM* when plugging it in to USB.
USB devices are “plug-n-play”. Those devices can self-describe as to what they are upon plugin. When a plug-in event occurs, the hot plug layer will broadcast the device’s description. Other than this, the USB side is just a data pipe and has more or less done its job. The drivers which see this hot plug event have the choice to take ownership of the device. If you have both of the drivers for the two brands of serial USB UART chipsets, then each driver will know descriptions it can take ownership of, and ignore plugin events for other types of devices.
Normally USB works, but people tend to think USB failed when something goes wrong. Two things can go wrong: (A), the driver is not present, and so hot plug can’t hand ownership over (the driver won’t take ownership), or (B) there is no association between the driver and the description provided by the device. The latter is typically the case when a company uses a standard chipset but rebrands it such that you need a new association rule for the rebrand that binds the device to the driver. The former argument, (A), is usually not the case on Jetsons, because normally they have those drivers. If not, then it isn’t broken USB. You can get an actual USB error due to signal quality issues, and this does happen.
To distinguish between those errors you probably need to monitor “dmesg --follow”. This continuously views the kernel log. Then plug in the USB device. The log lines which occur as a result of that plug in event will answer which of those errors is at fault (you don’t need the log lines which occur prior to this).
I’ll add a different error which is specific to USB (not to hot plug), but which does not normally occur: If you have the wrong firmware due to flashing with NVIDIA software when the carrier board is really from a third party, then USB itself tends to not be found correctly by the USB drivers. The USB root HUB is itself not plug-n-play, it sits at a physical address on a bus, and the firmware is how the kernel is told where the root HUB is at. Custom carrier boards tend to use a different layout by means of the I/O assignments to pins being flexible to aid in easier carrier board layout.
So what we need is for you to run “dmesg --follow”. Then plug in the USB device, and post what log lines occur as a result of the plugin event. Also, we need to know if this is a third party carrier board, or if it is a dev kit. Finally, we can use the software release that is running, which you can find via:
head -n 1 /etc/nv_tegra_release
If you don’t know if this is a dev kit or not, then you might post the output of “cat /etc/nv_boot_control.conf”.
Note that 85-brltty.rules is one of those rules which associates custom hardware to particular drivers. Unless this is the related Braille hardware, then it is unlikely you will change anything by removing or adding Braille driver associations.