To verify, the PCIe card provides USB ports, is that correct? If this is working, the lspci should show the presence of the card. Note that PCIe should find the card even if a driver specific to the card is not present. Once PCIe sees the card, a hardware-specific USB root HUB driver can be loaded.If not, then the USB root HUB driver cannot be loaded and the USB controller is inert. If lspci shows the device, then the USB controller can be active with the presence of the right driver.
If the USB controller is active, then plugging in a USB device should cause the device to be seen in lsusb, and an event to be noted in dmesg about any USB device plugged in or unplugged…if this does not happen it implies the HUB internal to the card has no driver. Should this event be noted, there will not yet be a “/dev” file created…but it means the device special file can be created if the message of device insert on dmesg triggers a driver to claim ownership of the device. It is this final driver which creates the actual “/dev” file. The dmesg is from the same event which asks for the final driver to take ownership…no message, then nobody is asked to take ownership.
In many cases the final driver file is present by default for some standardized class of device (e.g., human interface devices like keyboards and mice). Should the device be custom (custom hardware not handled by generic class definitions), then a custom driver must be added.
Regardless of custom driver or standardized device class driver, some third party user space application or management daemon may not find the device special file if udev has used a naming convention not known by the application or daemon.
The observation that plugging the USB device into a non-PCIe USB controller generates an event, but plugging into the PCIe USB controller does not generate an event, shows the PCIe subsystem never got an answer from a driver that understands the USB root HUB in it (PCIe has broadcast an event to ask for a USB root HUB driver since lspci shows it, but no driver knows it can handle this PCIe HUB and does not respond). Note that lspci itself shows that the PCIe bus sees a device…but this does not mean a driver has taken control of the device (the USB hardware in the card). If the PCIe card used the same chipset as the other USB port which works, then you would have had a driver to take control; it looks like the PCIe card uses a different chipset than what current drivers support. You need a driver for the USB card’s specific chipset.
In cases where PCIe broadcasts the presence of a PCIe device, and in which some driver answered to take ownership, “sudo lspci -v” names the driver which answered. An example of what that answer shows up like via “sudo lspci -v” will look like this:
Kernel driver in use: ahci
If that line does not exist or if a line claims no driver, then you are guaranteed the USB root HUB driver specific to the PCIe device is at fault (it is missing or misconfigured). No USB hotplug event can be broadcast because the USB hardware is inert.
I have not read through all of that documentation of that card, but if there is some compatibility issue with the driver, or some missing configuration, then this would be the same as not having a driver for the chipset. What is the source of your GobiSerial.ko module?