This may seem long and complicated, but probably that’s only because I’m explaining what leads up to this problem…it seems your PC kernel is simply newer than the Jetson kernel. What follows is an explanation of finding out what went wrong and how to “back port” the feature…but this is really so simple your main effort will simply be in taking your current kernel configuration, saving it for use in a new and edited kernel, and then flashing as needed. I’m not covering flash, but once you see what is needed we can add details as necessary for building and installing the edits.
If I go here I do see product ID 2021 listed:
https://cateee.net/lkddb/web-lkddb/USB_SERIAL_PL2303.html
If I go to the kernel source as provided for the TX1 on R28.2 and look at this (which is what you get with “CONFIG_USB_SERIAL_PL2303=y”):
drivers/usb/serial/pl2303.h
…I see:
#define PL2303_VENDOR_ID <b>0x067b</b>
#define PL2303_PRODUCT_ID 0x2303
Note that 067b is the “manufacturer” ID, and not the vendor ID, as reported in lsusb. Either the driver in 4.4.38, for L4T, is incorrect in using manufacturer ID in place of vendor ID, or else the vendor ID is not known, or else the device itself has made a mistake (explained below, this was updated in 4.4.168). Calling the manufacturer ID the vendor ID is probably a mistake (though a text description from dmesg won’t necessarily be wrong send the manufacturer listed is correct), but in newer kernels this won’t matter since having all devices using the same driver mix and match labels won’t change how it functions.
Bottom line though: The pl2303 driver on the TX1’s 4.4.38 kernel does not recognize the device because the driver uses 0x067b instead of 0x0557 on manufacturer ID. Your manufacturer is indeed 0x067b, but this is not what the driver should be using to see compatibility. The table of device IDs lacks 0x0557 in combination with 0x2021. A bit of editing can fix this by adding the 0x0557 version.
So it is worth explaining something in the USB chipset industry. Every chipset manufacturer has registered with usb.org, and has a unique ID issued (this is the idVendor). This chipset might be used in either its own product or a third party product. If the manufacturer of the chipset and the product are the same, then vendor ID and manufacturer ID are the same. If someone purchases a chipset from a chipset vendor, and has the money to register IDs, then the vendor ID and product ID are unique to that manufacturer; on the other hand, if the manufacturer is using a standardized part from some chipset they did not create, such as FTDI, then the original chipset manufacturer vendor ID and product ID can be used…FTDI allows purchase of USB serial UARTs pre-burned with their vendor and product ID, or optionally blank so that the manufacturer using their chipset can completely customize. Both are valid. Your 0557:2021 is a third party chipset used by manufacturer 067b.
Regardless of whether the vendor and manufacturer use only the vendor’s ID, or a custom manufacturer setup, the chipset uses the same driver. There is a table of ID combinations which all use the same driver. Your chipset obviously uses the pl2303 driver.
I believe the newer kernel version on the desktop PC understands the idVendor of 0x0557 simply because it was updated (the desktop PC has a newer kernel version). I hate to say it, but because the feature was compiled directly in you may need to edit this in the kernel source and replace the kernel itself using the edited version. It wouldn’t be technically correct since 0x067b is also valid, but you could simply edit this line in “drivers/usb/serial/pl2303.h” (I recommend against this, it is only for illustration):
- #define PL2303_VENDOR_ID 0x067b
+ #define PL2303_VENDOR_ID 0x0557
To actually do this correctly you’d update the table of vendor/product IDs used by the driver by editing “drivers/serial/usb/pl2303.h” and the “.c”. In “pl2303.h” you’d go to this block and add a new line:
#define ATEN_VENDOR_ID 0x0557
#define ATEN_VENDOR_ID2 0x0547
#define ATEN_PRODUCT_ID 0x2008
[i][u][b]// This would be added so we can name iProduct 2021:
#define ATEN_PRODUCT_ID2 0x2021[/b][/u][/i]
…and then in “pl2303.c” you’d register the new combination of IDs. You’d find this block, and then insert code:
...
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
[i][u][b]// NEW CODE LINE...note the "2"...this combines iVendor and iProduct to allow your case:
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },[/b][/u][/i]
{ USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
This means regardless of whether there is a bug in checking manufacturer ID when scanning the device or not that the combination of IDs would correctly find the device driver is associated with your device.
If you need information on building the kernel (and modules as well since the base kernel is being edited) you can ask. Do take your running Jetson’s “/proc/config.gz”, save a reference copy somewhere safe, and gunzip it and rename it as “.config” for your starting configuration. CONFIG_LOCALVERSION would normally be “-tegra” if you wanted to match the module search location, but such a change as this implies it should be something custom, e.g.:
CONFIG_LOCALVERSION="-pl2303"
Honestly, if this is just a serial UART cable and there is nothing special about it, I’d just switch to an FTDI cable. If it is part of something else, then you’ll need to go through the extra effort due to the driver missing the 0557:2021 ID combination.
This looks like it was corrected in 4.4.168 (this may have been corrected earlier than that, but this is the version I examined), and if you want to see how the actual changes were arranged, see this and compare the combination of vendor and product IDs being put in the table:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/serial/pl2303.h?h=v4.4.168
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/serial/pl2303.c?h=v4.4.168